El famoso signo de exclamación

Cuando los computadores Atari recién llegaron a Chile, practicamente todos los juegos que se podían encontrar en cassette usaban el famoso cargador del signo de exclamación.  Se iniciaba la carga de cassete encendiendo el computador con las teclas OPTION + START presionadas, sonaba un beep, se presionaba una tecla y después de unos 10 segundos sonaban unos 6 “pitos” y aparecía un signo de exclamación en la parte inferior derecha de la pantalla, luego pasaban unos 10 segundos más y comenzaba a sonar la carga del juego en sí, a veces amenizada por alguna simple pantalla de presentación.

Si algo fallaba durante la carga, se debía comenzar desde cero, por lo que toda la ansiedad acumulada durante los varios minutos de carga se veía absolutamente recompensada cuando finalmente aparecía el juego en pantalla.  Posteriormente aparecieron mejores sistemas de carga aplicando “turbo” (mayor bitrate) y un mecanismo de recuperación de errores que permitía continuar la carga desde el punto de falla y así no comenzar todo desde cero.  Estos sistemas de carga avanzados merecen un artículo propio, lo que vamos a ver acá es el cargador original del signo de exclamación.

Básicamente estos sistemas de carga funcionaban así: Al iniciar el sistema, la tecla OPTION presionada indicaba al sistema operativo del ATARI que desconectara la ROM del lenguaje BASIC (su espacio era ocupado por muchos juegos), y la tecla START indicaba que se quería hacer un boot desde cassette.  Cuando el usuario presionaba una tecla después del beep, el sistema operativo del ATARI cargaba un archivo y lo ejecutaba.  En el caso de practicamente todos los juegos, este archivo era un cargador un poco más inteligente que se encargaba de cargar el juego en un formato más flexible (XEX).  Si vieramos la cinta como un esquema, sería así:

| ------- CARGADOR EN FORMATO BOOT DE ATARI -------|---------- JUEGO EN FORMATO XEX ----------|
| CARRIER - BLK1 - BLK2 - BLK3 - BLK4 - BLK5 - EOF | CARRIER - BLK1 - BLK2 - ... - BLKn - EOF |

Siempre quise saber exactamente qué hacía el código de este cargador tan simple, y por qué era tan grande (unos 640 bytes). Gracias al usuario AsCrNet de AtariWare que me envió un dump del cargador pude finalmente decodificarlo y ver qué hacía.

Formato XEX

Para que sea más fácil entender el cargador conviene entender primero cuál era el formato del archivo que procesaba el cargador, el formato “del juego”.  Este formato es conocido con el nombre XEX y tiene más o menos la siguiente estructura

|---------------- Archivo en formato XEX ------------- ...
|------ ENCABEZADO ------ | DATA |------ ENCABEZADO -- ...
|FF FF INIL INIH ENDL ENDH| DATA |FF FF INIL INIH ENDL ...

Un archivo XEX son varios bloques de datos.  Cada bloque comienza opcionalmente con un marcador con la secuencia FF FF (hexadecimal), luego viene la dirección de inicio expresada como 2 bytes (INIL INIH) y la dirección de término expresada también como 2 bytes (ENDL ENDH).  Estos 6 bytes son la cabecera del bloque, luego vienen los datos propiamente tal.  Por ejemplo si el juego tiene dos bloques, uno desde 32768 hasta 40959 y otro desde 3072 a 4096 veríamos la siguiente secuencia hexadecimal

|---------------------------- Archivo en formato XEX ----------------------------|
|--------------- BLOQUE 1 ----------------|------------- BLOQUE 2 ---------------|
|--- ENCABEZADO ---|-------DATOS----------|--- ENCABEZADO --|-------DATOS--------|
|FF FF 00 80 FF 99 | 16384 bytes de datos |FF FF 00 0C FF 0F| 1024 bytes de datos|

Después de cargar cada bloque, el cargador ejecuta una llamada a la dirección apuntada por el par de direcciones 738 y 739 ($02E2, $02E3).  Si el cargador quisiese ejecutar un código durante la carga, por ejemplo para mostrar una presentación, debía poner un bloque que escribiera en esas direcciones.  Supongamos que el código que muestra la presentación está en la direcció $0A3B, entonces aparecería un bloque así:

FF FF E2 02 E3 02 3B 0A

Cuando se llega al final de la carga, se transfiere el control al código apuntado por las direcciones 736 y 737 ($02E0, $02E1) utilizando el mismo esquema recién explicado.

El cargador

El cargador tiene el formato de BOOT propio de Atari, obviamente ya que de otro modo el sistema no lo podría ejecutar.  El sistema de BOOT de Atari comienza con 6 bytes para definir el número de bloques de datos, la dirección de inicio de carga y la dirección de ejecución.  En este cargador vienen los valores (hex) : 20  05  00 07 20 07 que son interpretados como : 5 bloques cargados a partir de $0700, inicio de ejecución en $0720. Por qué suenan 6 bloques de carga y acá dice que son 5? Porque son 5 de datos y el 6to es el EOF (End of File).

Si bien la dirección de ejecución es $0720, el sistema operativo de Atari primero ejecuta lo que está a continuación de este encabezado, en este caso es lo que está en $0706.  Y ahí comienzan las sorpresas!!!

Lo primero que me llamó la atención es que eset vil cargador está protegido.  Si uno trata de ver el código directamente, no se puede a menos que se vaya revisando la ejecución paso a paso.  Lo primero que hace el cargador es automodificarse para comenzar a ejecutarse en una dirección diferente a la que viene cargada originalmente. De la siguiente forma (ordenado por legibilidad):

BOOT:
706  32 244   8  JSR STOPANDPATCH ; $8F4

[...]

STOPANDPATCH:
8f4  32 207   8 JSR MOTOROFF
8f7  32 213   8 JSR PATCHJSR
8fa  96         RTS

MOTOROFF:
8cf 169  60     LDA #60
8d1 141   2 211 STA 54018
8d4 96          RTS

PATCHJSR:
8d5 169  32     LDA #32   ; JSR
8d7 141   9   7 STA $709
8da 169 157     LDA #157  ; $9D
8dc 141  10   7 STA $70A
8df 169   8     LDA #8    ; $08
8e1 141  11   7 STA #70B
8e4  96         RTS

Cuando se ejecuta PATCHJSR se modifica el código que se ejecutará justo después de volver via RTS en $8D4, para que salte a $089D, y qué encontramos ahí? La rutina que desprotege el resto del código invirtiendo todos los bits mediante XOR #$FF, una ténica que podríamos considerar milenaria.

A partir de ese momento, el código queda legible completamente.

No voy a analizar el detalle del cargador, pero sí me interesa destacar las siguientes curiosidades:

• No logré identificar la parte en donde se pone el signo de interrogación en la pantalla.  Sólo veo la impresión de un caracter que limpia la pantalla.  Será el signo de exclamación un bug del sistema operativo del Atari?
• El código de carga XEX en este cargador es HO-RRI-BLE.  Esto se debe principalmene a que está mezclada la llamada a las rutinas del sistema operativo para cargar datos desde cassette, con la interpretación de los encabezados XEX. En comparación, cargadores más modernos como CAIN (ahem!) usan una abstracción tipo stream, en donde los bytes se procesan uno a uno y la carga física de los bloques se procesa en forma independiente, como si se tratara de un sistema opaco subyacente (le puse color ah).  En todo caso, se entiende que sea así, hay que pensar que ese código debe ser de principios de los ’80, cuando muchos de nosotros no sabíamos ni ir a comprar el pan.
• Si la carga falla en algún momento, se invoca a la rutina del sistema operativo que imprime BOOT ERROR.  Por algún motivo, en los computadores que conocí esto nunca fue así, y el sistema simplemente se colgaba.  Es probable que la dirección de rutina haya sido válida sólo para equipos antiguos (400/800) y no para sistemas operativos más modernos (XL/XE).
• Se nota que el código fue parchado a nivel binario, ya que usaron NOP en varias partes, desactivando código.
• Derivado de lo anterior, hay muchos accesos de 16 bit a direcciones que están en la página cero, en donde se pueden usar instrucciones especiales que direccionan con sólo 8 bits (ej, 133, 2 en vez de 141, 2, 0).
• Si hay un cartridge insertado, aparece un mensaje en pantalla que lo advierte.  Este mensaje nunca lo había visto, y es muy probable de que hasta el momento nadie lo haya visto tampoco!  Les adjunto una captura al final de este artículo foryourpleasure.

Para quién quiera ver el detalle de cargador, les dejo los siguientes archivos en una carpeta de DropBox:

• casboot.asm : Archivo de texto con el código del cargador. Lo decodifiqué a mano, por lo que el código no es compatible con ningún assembler.
• dump.c : Programa en C para hacer un dump del código que me envió AsCrNet.  Al cambiar UNPROTECT a 1, se aplica el XOR #$255 para desproteger el código
• casboot.atr : Imagen de disco que contiene un pequeño programa en BASIC que hice para saber cómo se vería el mensaje del cartridge insertado (cartmsg.bas)

PD1 : La imagen del cargador que encabeza este artículo es un fake.  Fue lo más rápido que pude hacer.

PD2 : Por algún motivo se borró la mitad de este artículo mientras lo estaba creando. Lo tuve que hacer de nuevo. NOT FUN.

PD3 : Ningún juego fue dañado durante la creación de este artículo.

ACTUALIZACIÓN: Gracias a los aportes de Guillermo Fuenzalida y ArCrNet finalmente fue resuelto el enigma del signo de exclamación.  Cuando el cargador imprime el caracter de limpiar pantalla, lo hace con el siguiente código:

765 169 125     LDA #125   ; CLEAR SCREEN
767 32  164 246 JSR PRINT  ; $F6A4

Sin embargo la rutina del SO para imprimir en $F6A4 sólo es válida para la ROM de la generación Atari 400/800, porque en la ROM de los Atari XL/XE se encuentra en otro lugar.  Según Mapping the XL/XE:

Many 400/800 programs made direct jumps to keyboard ‘get’ and ‘put’ routines rather than through the proper vectors, which makes them incompatible with XL/XE machines. The get routines in the XL/XE begin at 62026 ($F24A). This was 63038 ($F63E) in the 800. The put routines begin at 62128 ($F2B0). or 63140 ($F6A4) in the 800. If you have a program which won’t work on your XL/XE, try finding if it uses these locations and change them.

Por lo tanto, el famoso caracter “!” de este cargador aparece debido a un bug sin mayores consecuencias.  Para comprobarlo, modifiqué la llamada a $F6A4 y la cambié por $F2B0 y efectivamente, se limpia la pantalla y no aparece el caracter “!”.  Lo mismo demostró ArCrNet usando el cargador en un emulador con la ROM del 400/800, nada de signo de exclamación.

Mensaje que aparece si hay un cartridge insertado

Con la publicación de mi artículo sobre cómo simplifiqué el acceso a mi colección de videos y música, tuve varias conversaciones con personas que habían hecho algo similar, y como en los asados, cada uno tiene su propia y “mejor” forma de hacer las cosas.

Para los amigos que aun están en la etapa de ver cómo hacerlo, quiero hacer algunas aclaraciones para ayudarlos a entender mi experiencia y el por qué de algunas decisiones que tomé en la implementación.

Creo que lo primero que conviene saber es qué es lo que ya había probado (y no era suficiente).  Por ejemplo muchas de las soluciones que me indicaron del tipo “pero es más fácil si …” eran justamente lo que tenía como punto de partida, y quería mejorar.

Implementación original

Incialmente tenía un Zotac Mag con XBMC conectado a uno de los televisores.  Este equipo tenía parte de mi contenido en su disco duro, y el resto lo leía desde una biblioteca compartida en otro PC via red.  Este es el equivalente a tener por ejemplo un computador con una biblioteca de iTunes compartida y un AppleTV o un Mac Mini conectado al televisor actuando como reproductor.

Esta solución tiene varios problemas para mis necesidades personales:  Uno es que necesitas tener al menos un equipo siempre encendido, en este caso el que comparte la biblioteca (sea iTunes u otro), y si es un Apple, necesitas además tener un reproductor Apple por cada televisor.  Si no es Apple, pues es lo mismo que ya tenía con el Zotac Mag.  Por otra parte, el contenido del disco del Zotac Mag no podía ser compartido fácilmente.

Mientras tanto, el segundo televisor no tenía nada conectado, y la única forma de acceder al contenido era sacando el disco USB con mi biblioteca para conectarlo directamente al PC.  Engorroso si son las 2AM o estás compartiendo un buen momento con otra persona. Ni hablar si eso implicaba copiar archivos o que el televisor no pudiera reproducir los archivos.

Pensé en algún momento conseguir otro equipo como reproductor, pero en el camino y por otros motivos, me hice de un GoogleTV y un AndroidTV, ambos con capacidad de reproducir contenido via DLNA.

Entra el NAS

Para eliminar el equipo que siempre está encendido, fue donde recurrí al NAS.  También es un equipo que siempre está encendido pero tiene ventajas bien interesantes:  Su consumo de energía es mínimo, es un server puro (no hay capacidad ociosa), y ocupa tan poco espacio que es como si no existiera.

Aca pueden ver una foto del NAS, y para apreciar su reducido tamaño, le puse encima un DigiPass, que es del porte de un llavero.

NAS junto a un DigiPass

Tener el NAS es como si mi biblioteca estuviera simplemente “en la red” de mi casa.  Es tan pequeño que el router motorola de VTR parece una torre al lado de él.  Lo único molesto es su led rojo cuando está encendido, pero se nota sólo si la pieza en donde está tiene todo apagado.  Tampoco tiene ventiladores, por lo que es absolutamente silencioso.

Los reproductores

Para la reproducción de video, independiente de que ocupara XBMC, un computador con VLC, un televisor Smart, GoogleTV, Android TV, etc, el denominador común siempre terminó siendo DLNA.  Es más, en el televisor Smart sólo enchufas el NAS y te aparece lo que muestra la foto de abajo.

NAS en LG Smart TV

Una de las críticas a mi implementación era que era “muy hacker”.  Pero las “hackers” de mi casa no tienen mayor problema presionando el botón “input” para seleccionar el NAS.

Acá hay una captura de lo que se ve cuando selecciono el NAS en el televisor.

Selección de videos del NAS en LG SmartTV

Por el lado del televisor “no smart”, este ya se encontraba conectado a un GoogleTV. Lo único que me costó fue decidir qué aplicación usar para acceder al NAS, y justamente escribir este artículo es para ahorrarles ese tiempo. Basta instalar MediaHouse desde Google Play, seleccionar el NAS y listo, verán las mismas carpetas que se ven en la foto.

Transcodificación

El no poder reproducir el contenido por encontrarse en un formato no procesable por los reproductores es algo que sólo se puede evitar conectando un computador con XBMC o VLC al televisor, en donde la disponibilidad de codecs es infinita.  Pero eso es volver al punto de inicio, cuando ya tenía el Zotac Mag con XMBC.  Lo mismo sería conectar un Mac Mini o un AppleTV, es volver al punto de inicio del que quería escapar.

La transcodificación tiene sus pro y sus contras. El principal contra es que es un proceso lento, dependiendo del computador puede tomar unos 10 minutos por hora de video.

A su favor tiene varias cosas, sobre todo considerando que el video se transcodifica sólo una vez. Vamos viendo:

• El archivo resultante generalmente es más pequeño que el original, dependiendo del bitrate seleccionado.  Por ejemplo muchos DVD’s de 4.7GB terminan convertidos en archivos de 500MB con la misma calidad aparente.
• Se puede integrar en un solo archivo el video con sus subtítulos, nada de andar con los archivos sueltos por ahí
• Muchos de los videos en HD que pululan en la red ya están en el formato correcto (MKV/H.264), no hay que transcodificarlos
• El archivo SIEMPRE funcionará en todos los dispositivos.  Aquí your mileage may vary porque depende de tus dispositivos.
• En mi caso, la mayoría del contenido que estoy moviendo al NAS lo tengo originalmente en DVD, por lo que la transcodificación es INELUDIBLE.  Por otro lado, la ganancia en espacio físico es altísima, ya que el CD/DVD se puede descartar una vez transcodificado.

Lo que no se vió

Hay una parte del proceso que quizás confundió a algunos que lo encontraron “muy hacker” y fue la actualización del firmware para instalar Snake OS.

En la realidad, los “complejos” pasos fueron:

• Conectar el NAS a la red
• Encenderlo
• Abrir la página web de administración (como si fuera un router)
• Seleccionar el archivo con SnakeOS y darle Aceptar
• Esperar a que terminara la instalación y posterior reinicio.

Video en 1080p corriendo sobre LG SmartTV conectado al NAS

Los costos

La parte de costos no es menos importante.  No me gusta llenarme de equipos con capacidades que no voy a usar, y si puedo reutilizar algo que ya tengo, mejor aún.  Por otro lado me si voy a gastar en algo, tiene que ser proporcional al uso que le voy a dar.  Como a veces le digo a mis amigos, para qué quiero un auto caro si pasará casi todo el tiempo estacionado.

Esto era lo que ya tenía antes de comenzar esta implementación:

• 1 Televisor con soporte de DLNA
• 1 Televisor sin soporte de DLNA
• 1 Google TV enchufado al televisor sin DLNA
• 1 Disco duro de 500GB que me sobró cuando le cambié el disco al Mac Mini
• 1 Red Wifi

Estos fueron mis costos en hardware:

• 1 NAS : USD$40
• 1 Adaptador para el enchufe : USD$1

Total : USD$41 (unos CLP$20.500)

Mis costos en horas hombre (aproximado):

• Actualización del Firmware : 5 minutos considerando lo que tuve que leer

También hay costos del “noviciado” y que se evitarán con este par de artículos sobre el tema. No tengo estimaciones ni tampoco interesa mucho, porque no tendrán que pasar por eso nuevamente:

• Reformatear disco NTFS a EXT
• Buscar solución al problema de Mac OSX con versiones antiguas de SMB
• Probar el codec que funcionara mejor, junto a su configuración

A modo de comparación de costos, aquí están los costos calculados de las alternativas “más fáciles”, pero que tenían el pequeño inconveniente de ser iguales a mi problema original, el que ya tenía solucionado:

Alternativa 1:

Time Capsule + 1 Mac Mini por cada televisor, o sea 2 Mac Mini

• 2 Mac Mini = 2 * CLP$384.000 = CLP$768.000
• 1 Time Capsule para alojar la biblitoeca (2TB) = CLP$192.000

Costo total sólo en hardware : CLP$960.000

Una diferencia de un 4.800% con el costo de mi implementación.

Alternativa 2:

1 Mac Mini + 1 Apple TV por cada televisor, es decir, 2 Apple TV

• 2 Apple TV = 2* CLP$76.000 = CLP$152.000
• 1 Mac Mini  = $384.000

Costo total sólo en hardware : CLP$536.000

Una diferencia aproximadamente de 2.600% con el costo de mi implementación.

Además hay que agregar que con un sistema basado en Apple no podría acceder al contenido desde los 2 computadores con Linux que además se usan en la casa, ni los Android’s.

En mi caso personal también podría descontar el Mac Mini, porque hay uno.  Pero ni loco lo dejaría encendido 24×7.  Aún así la implementación sería un 700% más cara que lo que conseguí finalmente.