Como Imprimir un Entero de 32 Bits en ASM

printf(“Imprimir en ASM no es tan facil como tu crees”);

El semestre en las universidades termina y con ello baja la cantidad de visitantes, dejando solo aquellos que vienen por gusto o porque realmente les interesa el ASM. Esta vez traigo un programita que convierte un valor binario de 32 bits en una cadena ASCII-Z.

Ya se lo que se han de estar preguntando los que no estan muy familiarizados con la programación en ensamblador: ¿Porque este desperdicia espacio en una tontería como esta? O peor aún ¿Y que este idiota no sabe que los números son diferentes a los “strings”?

Mientras mas avanzo en esto del Ensamblador mas me doy cuenta del daño que causa a a los programadores principiantes el empezar su aprendizaje con lenguajes de “alto nivel” (como me fastida ese término). Por todos es bien conocido el daño que hace iniciarse a programar con BASIC y todos sus descendientes y tal parece que cada nueva versión de BASIC tiene nuevas y mas novedosas maneras de echar a perder a los programadores mas jóvenes. No cabe duda de que el daño hecho por iniciarse en este tipo de lenguajes es muy dificil de remediar. Si me pusiera a enumerar todos necesitaría otras 3 entradas nada mas para el puro BASIC, pero en este caso creo que voy a blasfemar un poco.

Todos saben que como radical que soy, tengo muy poco respeto por la mayoría de los lenguajes autodenominados de “alto nivel”. Excepto por el viejo C que es el que mas se acerca al ASM. Sin embargo, para quienes se inician programando en C o alguno de sus derivados mas amistosos topan con piedra a la hora de comenzar a programar en ASM. Pues cosas que son relativamente sencillas en estos lenguajes son completamente diferentes, cuando no imposibles en ensamblador. Esta lista merece su entrada a parte pero el asunto a discutir ahora es la modesta función printf( );

printf(“La suma de %d + %d es igual a %d”,numero1, numero2, resultado);

Veamos los parámetros: el primero es una cadena de texto con signos de control que son remplazados por el contenido de las variables numéricas llamadas numero1, numero2 y resultado. Pero este proceso no es directo, primero la función debe de procesar por medio de un aceptor la secuencia de signos que se encuentran entre las comillas dobles e interpretar los signos de control como instrucciones. ¡En realidad esta sencilla cadena de caracteres puede considerarse un programa completo!. Y lo que dice es: Toma los 3 números cuyos valores te envío por el Stack, conviertelos en strings decimales e intégralos con el resto del string y luego le dices al sistema operativo que los despliegue. Eso sin mencionar la comprobación exhaustiva de tipos de las variables ni los formatos numéricos en los que debe de ser mostrado. De hecho, la leyenda de que una sola instrucción de C se convierte en cientas o miles de instrucciones en ASM es cierta sobre todo por instrucciones como printf(); y scanf();

Bueno, ahora que ya saben que un printf no es tan sencillo como parece vamos con el código:

;BIN2ASC.ASM
;Escrito por Mario Salazar el 11 de diciembre del 2009
;http://asm86.wordpress.com
;http://itzasm.ning.com
;Programita que despliega un numero de 32 bits en hexadecimal
;por medio de MessageBox. Para compilarlo con FASM solo presione
;la tecla F9. El numero solo puede ser cambiado en el codigo
;Lean el archivo bin2asc.xls para una referencia de las variables

format PE GUI
entry start

section '.code' code readable executable

  start:

			mov [eax_bin], 1234abcdh
		   ;cambia el 1234abcdh por el numero que quieras entre 0 y 2^32

			call bin2asc
		   ;llamada a la funcion que convierte ese numero en cadena ascii-z

			push	0
			push	debug_caption
			push	eax_ascii
			push	0
			call	[MessageBoxA]
		   ;mostrar una MessageBox que despliegue el numero

			push	0
			call	[ExitProcess]
		   ;terminar el programa

bin2asc:
			pusha
		    ;guardar los registros generales en el stack

			xor	eax, eax	 ;prepararse para el ciclo y
			mov	ecx, 8		 ;cargar valor binario en edx
			mov	edx,[eax_bin]
    lee_binario:
			mov	ebx, 0fh	 ;extraer los 4 bits mas bajos
			and	ebx, edx	 ;con una mascara de bits
			mov	al,  [ebx + digitos]
			push	eax		 ;usar esos 4 bits como indice
			shr	edx, 4		 ;a la tabla digitos
			loop	lee_binario	 ;por cada 8 numeros
		    ;obtener 8 simbolos ascii y guardarlos en el stack

			mov	ecx, 8
			mov	edi, eax_ascii	 ;apuntar edi a la cadena ascii
    escribe_binario:
			pop	eax
			mov	[edi], al
			inc	edi
			loop	escribe_binario
		    ;sacar los simbolos ascii del stack y
		    ;guardarlos en la cadena ascii

			popa
			ret
		    ;restablecer los registros generales y terminar proceso

section '.data' data readable writeable

	eax_bin 	  dd	   0			      ;valor binario a convertir
	debug_caption	  db	   'Hex de 32 bits:',0	;nombre de la ventana
	eax_ascii	  db	   '00000000',0 	      ;cadena de salida
	digitos 	  db	   '0123456789ABCDEF'	      ;arreglo de simbolos hexadecimales

section '.idata' import data readable writeable

  dd 0,0,0,RVA kernel_name,RVA kernel_table
  dd 0,0,0,RVA user_name,RVA user_table
  dd 0,0,0,0,0

  kernel_table:
    ExitProcess dd RVA _ExitProcess
    dd 0
  user_table:
    MessageBoxA dd RVA _MessageBoxA
    dd 0

  kernel_name db 'KERNEL32.DLL',0
  user_name db 'USER32.DLL',0

  _ExitProcess dw 0
    db 'ExitProcess',0
  _MessageBoxA dw 0
    db 'MessageBoxA',0

section '.reloc' fixups data readable discardable

En realidad la mayor parte del source pertenece al viejo PEDEMO.EXE del FASM. Pero no he “encapsulado” este “método” para que fuera mas sencillo de entender y a la vez mas dificil de lamear. Para compilarlo solo cárguen este programa en el IDE del FASMW y opriman F9. Pueden cambiar el número 1234abcdh por el que ustedes quieran ¡Incluso si lo dan en formato decimal o como una palabra de 4 letras!. Si hacen lo de las palabras con 4 letras (muchas de las cuales suelo gritarle a los lamers todo el tiempo) no olviden ponerla entre comillas dobles. No se asusten si de pronto alguna aparece al reves, se debe a algo llamado Little Endian que explicaré (de nuevo) otro día.

El programa tiene 3 elementos de datos:

eax_bin.- Es un espacio en memoria de 32 bits donde se va a guardar el dato a desplegar

eax_ascii.- Array de 9 bytes. Ocho son para los digitos y el ultimo en un cero binario que indica el fin de la cadena ASCII-Z

digitos.- Este es el mas importante. Es un array de bytes donde cada uno representa uno de los 16 digitos ascii que serán usados para formar la cadena de texto.

Ahora vamos con las instrucciones:

Antes y después de la función se guardan y restauran los valores de los registros generales con PUSHA Y POPA. Luego de guardarlos se escribe el entero de 32 bits en el registro EDX y en ECX se escribe un 8 en preparación para el ciclo de lectura que ha de repetirse 8 veces.

Hay un ciclo que lee el valor de 32 bits en porciones de 4 bits cada una, este ciclo está entre la etiqueta lee_binario: y la instrucción loop lee_binario. Para extraer los 4 bits mas bajos del registro EDX se hace un AND entre este y EBX que poco antes fue cargado con el valor 0Fh (quince decimal y 00001111 en binario) El resultado de este AND deja en EBX los 4 bits mas bajos del registro EDX y el resto los pone a cero. Esto es lo que los programadores de ASM llamamos “máscara de bits”.

Ahora viene lo interesante: Para convertir esos 4 bits en un dígito ASCII con una sola instrucción de lenguaje Ensamblador usamos EBX como offset del arreglo digitos. De modo que estos 4 bits (que solo pueden tomar valores entre 0 y 15) nos den la posición de memoria de su correspondiente dígito ASCII una vez que se sumen a la posición de memoria indicada por la etiqueta digitos. La instrucción que hace esto y guarda el resultado en la parte baja del acumulador EAX es MOV AL, [EBX + digitos]

Luego de esto, el acumulador completo se guarda en el stack con push y luego se hace un desplazamiento binario hacia la derecha de 4 bits en EDX con SHR EDX, 4. Con esto ahora los 4 bits mas bajos en EDX corresponden al siguiente dígito hexadecimal a transformar. Esto se repite 8 veces hasta que se obtienen todos los valores ASCII para formar la cadena hexadecimal de 32 bits.

La siguiente es bastante sencilla, primero se carga en ECX otro 8 para escribir los 8 digitos del hexadecimal de 32 bits. A continuación se carga en el registro EDI (Extended Destination Index) la posición de memoria de la zona donde vamos a escribir la cadena ASCII. Entonces, por cada ciclo vamos a ir sacando valores de la pila con POP EAX y escribimos los 8 bits mas bajos en la posición guardada por edi con MOV [EDI], AL e incrementamos el ‘puntero’ EDI con INC EDI para ir avanzando en la cadena.

Luego de estos 2 ciclos restauramos los registros generales con POPA y devolvemos el control al llamador con RET. Es importante siempre restaurar los registros generales en Windows, sobre todo EBX, ESI y EDI antes de que el Windows vaya a hacer cualquier cosa, de lo contario podemos desatar su ira y nos echará abajo la aplicación.

Una cosa mas, por si no lo han notado en el primer ciclo los digitos de 4 bits se leen comenzando por el menos significativo pero a la hora de escribir se comienza por el digito mas significativo. Esto es posible porque usamos el Stack. Y como todos saben de la clase de ensamblador con Solis el primer elemento en entrar a estas estructuras es también el último en salir.

Ya para terminar, es importante poder convertir enteros binarios en cadenas ASCII porque la mayor parte de los sistemas operativos (o en este caso la API del Windows) no pueden representar números binarios facilmente. Además de que un mismo número binario puede ser representado en muchas formas diferentes dependiendo del sistema numérico (decimal, hexadecimal, fraccionario, etc.) mas adelante veremos como desplegar un número binario en formato decimal. En realidad solo basta con agregar 2 instrucciones y un dato de 1 byte a este mismo código. Les aconsejo que sean organizados con sus viejos códigos y los reutilicen tanto como les sea posible porque los programas escritos en ASM pueden llegar a ser enormes en source aunque su ejecutable tan solo mida unos pocos kilobytes.

Revancha de 32 Bits

–Y el Retorno de los Programadores de Ensamblador–

Esta es la cuarta y última parte de la Saga de 32 Bits. Donde se muestra como luego de ser desterrados por los lamers, los programadores de Ensamblador regresamos a reclamar nuestro lugar en los PC’s actuales basadas en Windows con CPU de Intel. Aunque algunos parece que aún no se han dado cuenta y en pleno siglo XXI siguen programando para los procesadores de 16 bits como el 8086.

Luego de escribir las tres notas anteriores revisé una vieja bitácora que comencé a escribir mas o menos por el otoño del 2000. Encontré una referencia de la primavera del 2004 en la que se menciona un primer intento por programar en ensamblador para Windows. Lo interesante de esta primera aproximación fue que en lugar de comenzar a programar como con cualquier otro lenguaje. Buscando tutoriales, libros y hablando con ‘profesionales de la industria’ lo que hicimos fue irnos directo contra el formato binario de los archivos ejecutables. Ya teníamos algo de experiencia estudiando código ejecutable de tiempos del DOS con sus famosos archivos de formato MZ. No puedo describirles la sensación que uno tiene cuando por primera vez abre un programa ejecutable en un editor hexadecimal y entiende lo que significan cada uno de esos números. Y mas aún cuando puedes manipular un archivo binario sin mas herramienta que un editor hexadecimal y ver como la aplicación cambia su conducta. En el caso del Windows este formato era conocido como PE (Portable Executable) y hasta tiene un encabezado compatible con MS-DOS que despliega un mensaje que dice “Este programa no puede ser ejecutado en DOS”.

Sin embargo, aún no éramos tan buenos como para programar 100% en lenguaje máquina a velocidad mas o menos razonable, y ahí comenzó la aventura de buscar programación de Windows en ASM. En ese entonces el FASM tenía muy poco soporte y no nos hallábamos con sus terribles Macros. Existían sin embargo otros 2 caminos: MASM y NASM.

El Netwide Assembler, mejor conocido como NASM era un ensamblador “popular” en el mundo de Linux (y escribo popular entre comillas porque en realidad a la gente de Linux no le interesa mucho el ASM) Su sintaxis era muy buena comparada con otros ensambladores de Linux y podía hacer código para DOS y Windows. Por un tiempo usamos este ensamblador, y aunque era excelente para programar nuestras viejas computadoras 486 con DOS, programar en Windows era demasiado complicado, pues necesitaba de un enlazador externo sumamente revoltoso de usar llamado ALINK para hacer programas compatibles con Win32. Eso sin mencionar que el NASM era sumamente ineficiente, era posible contar en segundos el tiempo que se tardaba en compilar un sencillo “hola mundo” y su ejecutable medía casi un mega completo. Además de que había demasiados pasos intermedios que no quedaba claro que hacían. Pero sobre todo, una cosa muy rara era el hecho de que un programa ensamblador tuviera su source code en C. Me imagino que como el C es el lenguaje de programación oficial de UNIX y todos sus descendientes lo hacían para mentener cierta compatibilidad. Al final decidimos abandonar el NASM porque a diferencia de otros proyectos de GNU Linux este estaba relativamente abandonado y sus contríbutors no parecía interesarles demasiado la programación en ASM, como a la mayoría de la gente que trabaja con Linux.

En cuanto al MASM o Microsoft Macro Assembler este en realidad casi no lo usamos. Sin embargo era necesario conocerlo muy bien porque la inmensa mayoría de los códigos de Ensamblador para Windows que encontramos estaban programador en él. Los tutoriales de Iczelion, los del Test Department, un Tetris en DirectX (del que hablaré dentro de poco) y la mayor parte de los códigos de las comunidades de Ensamblador para Windows fueron ensamblados con MASM. Lo siniestro del asunto es que Microsoft abandonó MASM desde mediados de los noventa y desde entonces ha sido mantenido con vida artificial por hábiles programadores de diversas partes del mundo. De hecho hay un programador conocido solo como Hutch que ha hecho mucho por mantener este viejo ensamblador funcionando en estos últimos años. Puede que lo que lo ha mantenido con vida haya sido su capacidad para generar viejo código máquina de 32 bits para los 486 pero de ahí en delante, el MASM no pasaba de ser un modelo antiguo con grandes remodelaciones de aficionados.

Al final solo quedaba el FASM, pero como ya se dijo los programas en Ensamblador para Windows eran muy pocos y casi todos estaban plagados de esas horribles macros que tanto fastidian a los principiantes. Por lo que en aquellos años la programación en ASM para Windows pasó a segundo plano para dar paso al desarrollo de software para la consola coreana de videojuegos mencionada en la entrada anterior.

De Vagabundo a Estudihambre

Y así pasaron un par de años hasta que mi familia me obligó a retomar mis estudios. En realidad no me interesaba estudiar y solo lo hice porque mi madre dijo que no se iba a morir hasta no verme titulado como el resto de mis hermanos, el si podría vivir o no de lo que estudiara le importaba, como se dice en México, 3 cacahuates. Y como tal, busqué una escuela cuya colegiatura me costara solo 3 cacahuates, donde nadie me conociera y sobre todo que al graduarme tuviera un título de ingeniero. Por obra y gracia de los dioses del tercer mundo encontré un lugar donde podía estudiar una carrera profesional por menos de 100 dólares americanos el semestre.

De esta escuela les hablaré otro día, lo que importa ahora es que a 3 semestres de haber entrado ahí el trabajo con los coreanos se fue por el retrete y sin jalarle. Por lo que furioso y con menos dinero decidí retomar la programación en ASM para Windows con todos los inconvenientes ya mencionados. Aún recuerdo como imprimí los tutoriales de Iczelion y el Space-Tris (Un Tetris en Ensamblador para Windows que usaba DirectX) y me encerré con lo que quedaba de mi antigua Pentium 100mhz de en ese entonces casi 10 años de antiguedad. Y como ambas fuentes de información estaban en MASM y yo programaba en FASM hizo falta de muchas horas con el BIEW y el OllyDbg mas documentos sobre el formato PE de Windows para lograr obtener toda la información que necesitaba y echar a andar los primeros códigos. Por desgracia ya era la segunda mitad de la primera década de este siglo y todo eso no me servía para mucho. En ese tiempo aprendí mucho de lo que actualmente se sobre como programar en ASM para Windows.

El Reto Final de los Vagabundos

Sin embargo la controversia seguía. Pues aunque ya era capaz de hacer las típicas aplicaciones GUI con Ensamblador aún faltaba el poder hacer verdaderos juegos, por lo que esa sensación de inferioridad no acababa de irse. Recuerdo especialmente una plática que tuve con el Julio en una época que habíamos considerado participar en un evento de animación y videojuegos llamado Creánimax. El decía que si queríamos participar íbamos que dejar momentaneamente el Ensamblador y programar en C++. Yo por supuesto como buen fundamentalista de la programación en ASM me opuse terminantemente a rebajarme a usar un lenguaje “para humanos”. Ahí fue cuando el Julio diera uno de sus discursos célebres:

–“Ya se que el ensamblador es como un Ferrari y que el C/C++ es un auto de calle como un Chevy (elijan el modelo que quieran) pero por ahora solo tenemos las llantas del Ferrari y no lo vamos a terminar de construir en un buen tiempo. Sin embargo ya tenemos completo el Chevy y puede llevarnos a donde queramos si arrancamos ahora mismo.”–

Palabras mas, palabras menos una semana después apareció con un modesto programa hecho en el tan odiado Visual Studio que escribía unos cuantos pixeles en la memoria de video y por una temporada estuvo haciendo algunas rutinas para manejo de sprites. Ahora que lo veo de lejos creo que si por lo menos hubiera hecho eso mismo con Code::Blocks y el MINGW (un derivado de GCC para hacer programas de Windows) lo hubiera aceptado un poco mas.

No estoy seguro de cuanto tiempo pasó entre eso y el momento en que yo por mi cuenta lograra hacer eso mismo programando completamente en Ensamblador; pero fue el suficiente para que el asunto de la participación en el Creánimax quedara olvidada. Finalmente, durante el verano del 2008 fue que logré hacer trabajar juntos al Windows Vista, los nuevos CPU’s multinucleo, el DirectX y al Ensamblador de manera verdaderamente eficiente de modo que podría tomar lo que mas me conviniera (abstracción de hardware de DirectX o programación directa de las Streaming SIMD Extensions) según considerara necesario. Luego de este evento tan trascendente en mi vida, ya no hubo mas necesidad de subestimar al Ensamblador a la hora de hacer proyectos serios. Sin embargo, apenas había aprendido a flotar en las orillas del océano y para ganar era necesario cruzar este a nado limpio. Aunque una de las cosas mas extrañas de esta aventura de programar en Ensamblador para Windows fue que los libros que mas me ayudaron a lograrlo no eran precisamente libros de Ensamblador, ¡Sino de Programación en C!. Por supuesto que estos solo me sirvieron para saber que era lo que estaban haciendo esos OpCodes porque al final donde los programadores de C veían esa horrible notación húngara yo solo veía agradables enteros de 32 bits y una que otra cadena ASCII-Z o Unicode.

Y como prueba aquí les dejo una captura de pantalla de una escritura en ensamblador directo a la memoria de video. El modo es el humilde 800 por 600 a 32 bits de colores. Cada uno de los renglones tiene una intensidad de color azul (256 intensidades). Los números a la izquierda son valores de 32 bits de una zona de la memoria. Para pintar estas lineas se usaron las instrucciones REP y STOSD de ensamblador. De modo que con esto se demuestra que no solo es posible programar en Ensamblador para Windows, sino que es posible obtener optimizaciones tan buenas como en la vieja época de los DOS Extenders. Y me haría falta esto y mas para poder manejar lo que estaba por ocurrir…

Nota al margen: Esta foto la tuve que tomar con una camara digital porque no hay manera de capturar la pantalla con PrintScreen al escribir directo a memoria. Es necesario copiarla manualmente a un archivo de imagen.

Por cierto, y nada mas para insultar. Hasta ahora casi no he encontrado juegos que aprovechen las nuevas arquitecturas de nucleo múltiple a toda su capacidad. Muchos de los juegos actuales no serían capaces de desplegar sus famosas gráficas sin la ayuda de costosas tarjetas aceleradoras de video y la verdad es esa misma calidad de imagen sin el uso de las GPU’s ya era posible desde la época del Pentium 4 (si las hubieran programado en Ensamblador por supuesto). Por cierto, a finales del 2008 y principios del 2009 fue que logré escribir directo al sistema de video en ensamblador para Windows Vista. Y nada mas para seguir insultando, no tuve ninguno de esos problemas de los que tanto se quejan los lamers del .NET y plataformas similares. Y aunque usé algunos antiguos servicios del DirectX para evitar problemas con la protección de memoria, no tuve necesidad ni siquiera de descargar e instalar el SDK ni mucho menos ninguna de esas bibliotecas Wrappers (que ocultan las llamadas a DirectX) que tan de moda se han puesto hasta entre los autodenominados profesionales de la industria.

Y este es el punto donde se queda esta historia. Si todo va bien, para dentro de uno o dos años voy a tener con que darle a esto de los juegos. O antes si alguno de entre los que leen este blog quiere unirse para participar y llevarse su parte es bienvenido. Hay que recuperar todo el tiempo y dinero perdido. Y hay que moverse rápido porque los CPU’s de 64 bits ya llevan algún tiempo en el mercado y aunque los sistemas caseros de 64 bits actuales son bastante inestables, ya comienzan a ser aceptados por los consumidores. Parece que la barrera de los 4 gigabytes de memoria está por romperse. Y no puedo esperar por programar una computadora con 16 Exabytes (lo que mediria una memoria de 64 bits). Seguro en 20 años, pues igual de lejanos se escuchaban los 4 Gigabytes en 1985.

Y este es el fin de estas 4 historias sobre la programación en Ensamblador de 32 bits. Al final la única moraleja que puedo dejarles a ustedes es la siguiente:

–Si no puedes contra el enemigo…  ¡Desensámblalo!–

Vagabundos de 32 Bits

¿Era ese el final de los Programadores de Ensamblador?

Esta historia es continuación de la nota anterior llamada “Desterrados de 32 Bits” que a su vez es continuación de “Revolución de 32 Bits” y cuenta uno de los episodios mas deprimentes en la historia de la programación en Ensamblador de principos de este siglo.

En la última entrada se cuenta como de la noche a la mañana, se volvió casi imposible programar en Ensamblador para computadoras con Windows basados en tecnología NT (como el 2000, ME y XP) y como muchos tuvieron que dejar de lado la programación en Ensamblador y rebajarse a manejar bases de datos para poder sobrevivir. Y de como mis compañeros programadores y yo decidimos hacerle frente a este destierro sin obtener lo que se dice los mejores resultados en el proceso. Sin mas, aquí está la historia:

El asunto no podía quedarse así, por lo que en ese entonces reuní a lo que entonces era mi pequeña banda de forajidos computacionales y en una junta tomamos una de las decisiones que, aunque tuvo muchas cosas buenas retrasó nuestro avance en el desarrollo de videojuegos por al menos nueve años. Ahí, frente a unos demos de DirectX, recuerdo especialmente uno de una calabaza de halloween que desplegaba un Framerate de 120 FPS, nos preguntamos:

¿Continuamos con la programación directa del hardware o nos metemos con DirectX?

¡Demonios! Si pudiera regresar el tiempo justo a ese instante me abofetearía a mi mismo hasta que solo me funcionaran el sentido del oido y el sentido común y me gritaría a mi mismo:

¡No seas 9*n3+@5! ¡Es perfectamente posible programar para Windows en Ensamblador!

Pero en ese entonces tenía un concepto muy equivocado sobre lo que era programar para Windows. Creía que la única manera de desarrollar para las versiones mas avanzadas de este sistema operativo era con herramientas como el Visual Studio y similares. Las cuales en ese entonces (o sus equivalentes de ese entonces) aunque eran buenas resultaban muy caras, extremadamente difíciles de conseguir, con infomación casi nula y aún bien dominadas el rendimiento del producto final no se comparaba con el de una aplicación programada completamente en Ensamblador. Por lo que, confiados en nuestra habilidad para programar en ASM tomamos una decisión tan valiente como ingenua: ¡Nuestros juegos debían de ser capaces de ejecutarse sin sistema operativo!

Hoy en día es mas o menos conocido el concepto de Live CD entre los aficionados a Linux. Y para los que no saben, un live CD es un disco que uno pone en una computadora y que es capaz de correr una aplicación completa sin necesidad de alterar en lo mas mínimo el sistema operativo instalado, y se usa para versiones de prueba de sistemas operativos. Nuestro plan era hacer juegos que funcionaran de la misma manera. Durante ese tiempo, que abarcó mas o menos 2 años aprendimos muchísimo sobre como hacer un sistema operativo y, al igual que cuando intentamos hacer un compilador propio y nos topamos con FASM, esta vez nos topamos con MenuetOS. Un interesante sistema operativo de Europa Oriental programado completamente en Ensamblador. Aprendimos mucho de esa experiencia, aunque mas hubiéramos aprendido de haber sabido hablar ruso. Algunas de las hazañas que conseguimos en ese entonces fueron:

• Arrancar una PC sin sistema operativo por medio de un Bootloader en Floppy y CD
• Hacer controladores de discos y periféricos para ese bootloader.
• Entrar al modo protegido desde ese bootloader
• Tomar control sobre el misterioso BIOS de 32 bits.
• Manipular el BUS PCI y todos lo periféricos conectados al mismo.
• Manipular las tarjetas de video de aquel entonces compatibles con el estandar VESA 2.0 y superior.
• Mover grandes cantidades de datos con el DMA de 32 bits.
• Y muchas cosas igual o mas impresionantes que al final no nos sirvieron para mucho.

Al final, ya cuando teníamos la capacidad de desarrollar software mas o menos decente que corriera desde un live CD (por cierto, en esa época las grabadoras caseras de CD eran tan caras como una computadora de escritorio) nos topamos de narices con que la gente no aceptaba ningun software que no corriera en Windows. Era una ironía que aún teniéndo la capacidad de desarrollar un sistema operativo completo si hubiéramos querido eramos incapaces de programar unos humildes juegos.

A partir de entonces no ocurrió nada bueno, salvo el haber levantado una pequeña oficina en un local que había permanecido abandonado durante cuarenta años. Y que a pesar de tener serias carencias nos sirvió bien para continuar nuestras investigaciones por los primeros 2 años de este siglo XXI. En ese corto espacio jugamos a ser una empresa de 3 (5 si contamos al Samuel y a Aldape) programadores sin documentos ni ganancias. Pero que logramos uificar todo lo que hasta entonces habíamos desarrollado.

Sin embargo, al pasar el tiempo y no lograr avances que fueran redituables el grupo se fue debilitando. Ya no éramos mas los programadores capaces de trabajar en un demo por 3 días seguidos de campamento en la oficina, algunos se vieron obligados a trabajar por hambre y necesidad. Eso sin mencionar que en ese entonces fue cuando me expulsaron de la universidad cuando ya iba en mi penúltimo semestre. El juicio fue algo traumático pero mas traumáticos fueron los meses antes y después del mismo. Y como ya comenté, no podré poner un pie en mi antigua facultad hasta bien entrado el 2024. Pero si regreso no va a ser como estudiante. Por cierto, mas o menos a la mitad del siguiente año fue cuando nuestro grupo de desarrollo acabó de desmoronarse por completo. Aunque aun nos veíamos ocasionalmente para planear estrategias que nunca llevábamos a cabo. Y aunque habíamos caído, aun no estábamos muertos.

Y aun estaba por venir lo peor…

Los siguientes dos años fueron los peores, no tiene caso que comente mis tragedias personales pero solo voy a decirles que en ese entonces fue cuando comenzó mi odio contra los lamers, pues en ese tiempo no encontraba trabajo ni como barrendero y el ver como todos los empleos en computación se los llevaban gentes cuyas únicas habilidades eran copiar querys, escribir documentos html (y no precisamente con un editor de texto), hacer clientes con editores de Visual Basic y trabajar con hojas de cálculo era algo que me enfurecía mas allá de los límites del razonamiento humano. Aún recuerdo como disimulé el asco al saludar de mano a un jefe de recursos humanos que tenía unas horribles manchas en la piel.

Y así pasé ese tiempo hasta que un día me llegó el chisme de que al otro lado del mundo alguien estaba desarrollando una nuevo consola de videojuegos y que no encontraba programadores. Esa pequeña aventura fue lo que me mantuvo vivo durante esos años negros y aunque no terminó como me hubiera gustado,si me hizo sentirme mejor conmigo mismo y me ayudó a reconstruir parte de mi antiguo equipo de desarrollo. Dicho aparato era conocido como GP32 de una empresa de Corea del Sur llamada Gamepark ubicada en Seoul. Espero poder escribir sobre ese asunto un día de estos. Pero supe que lo peor había pasado cuando, durante una sesión de programación con esta consola portatil, el buen Julio dijera:

–Te ves mucho mas repuesto que como te veías en los años de universidad… ¡En especial el último!

En fin, en el tiempo en que tuve esa consola coreana en mis manos recuperé mucho de lo que había perdido en años anteriores y si no fuera porque mi familia me obligó a rehacer mis estudios muy probablemente estaría escribiendo este blog desde algún lugar de Corea del Sur. Sin embargo, a pesar de esta gran victoria semipersonal (pues el Julio también colaboró muy de cerca) la programación para sistemas Windows había quedado abandonada durante siete años y dudo que en los 2 próximos años pueda hacerse algo que valga la pena vender. Apenas hace un año y luego de meses de ingeniería inversa y otras artes oscuras que no se si sea seguro mencionar en público es que logré hacer funcionar el ensamblador en una computadora con CPU de nucleo múltiple en Windows Vista. Y es ahora cuando realmente puedo retomar todo lo que dejé pendiente hace ya tanto tiempo.

Derrotados pero no muertos

Como se dijo en la nota anterior, este regreso a la programación en Ensamblador para Windows se debe en gran parte a los esfuerzos de grandes programadores como Iczelion, el autor del FASM Thomasz Grysztar, gente de sitios como asmcommunity.net y otros muchos mas que a partir de mucha investigación lograron devolverle su merecido lugar a la programación en ASM. En la siguiente entrada se hablará de este feliz regreso. Sin embargo, apenas se había descubierto el camino a seguir. El recorrerlo y llegar hasta el final era un esfuerzo de proporciones épicas, mismas que se detallarán en la siguiente nota donde además de eso se contará como los programadores de Ensamblador regresamos al territorio del que alguna vez fuimos cruelmente expulsados.

Destierro de 32 Bits

C:\>RUN\DOS\RUN>

Esta es la continuación de la entrada anterior titulada “Revolución de 32 Bits”.

La última nota trató sobre el como las PC’s equipadas con procesadores 386 y superiores abandonaron lentamente la programación en 16 bits para dar paso a aplicaciones mas avanzadas de 32 bits. Y como el mundo tuvo que esperar casi 10 años para ver juegos que realmente aprovecharan el hardware de estos entonces poderosos equipos. En esta parte de la historia se cuentan unos años horribles en los que llegué a pensar que era el fin de la programación en Ensamblador para computadora personales.

Corrían los últimos años del siglo veinte, poco a poco las conexiones de tipo Dial Up se volvían inoperantes y los primeros monitores LCD (de esos que si uno no estaba parado directamente de frente a ellos no se veían) comenzaban a aparecer. Esa era una época maravillosa en la que el DOS y el Windows 95 cohabitaban en la misma computadora y existía la controversia de que tanto uno dependía del otro. Tiempos en que el Windows NT solo existía en equipos empresariales y aunque era muy estable no servía para jugar. En ese tiempo aún había juegos que para jugarlos adecuadamente había que salirse del Windows. Pues correrlos desde dentro de este sistema, aunque era posible disminuían severamente su desempeño. La razón de esto era el Modo Virtual 86

Modo Virtual 86

Las computadoras de 32 bits (no recuerdo de momento a partir de que CPU) tenían una modalidad interesante de operación llamada Virtual 86 Mode, en que podían imitar no solo uno, sino a una multitud de sistemas de 16 bits y ejecutarlos como una subtarea independiente. De este modo era posible correr al mismo tiempo varias instancias del DOS con sus respectivas aplicaciones sin por ello salirse del Modo Protegido. Esto le dio mucha vida artificial a estas viejas aplicaciones aún a pesar de que hacía mucho tiempo que los CPU’s 8086 habían dejado de fabricarse. Sin embargo, cuando una aplicación de Modo Real trataba de inicializar el Modo Protegido desde el Modo Virtual 86 pasaban errores muy feos, como el Famosísimo Fallo de protección General, Ejecución de instrucciones privilegiadas, fallos de página y otras cosas peores cuya única solución casi siempre era un reset de la computadora completa. Eso sin mencionar que aunque esto no ocurrirera, uno solo tenía acceso a una minúscula fracción del poder de procesamiento y memoria del sistema. Por lo que las aplicaciones de 16 bits ejecutadas en el Modo Virtual 86 rara vez daban buenos resultados. Aunque siempre estaba la opción de reiniciar la computadora en modo MS-DOS.

¿Qué estaba haciendo Bill Gates mientras tanto?

Resulta que en su diseño original, Windows no estaba preparado para suministrar lo necesario para hacer buenos juegos. Su GDI (Graphics Device Interface) estaba pensada con la seguridad en mente y no en el alto desempeño que los juegos requieren. Por lo que, y esto lo leí en viejos libros de historia, intentaron hacer una biblioteca de funciones de 32 bits desde al menos el windows 3.1. Dicha mejora era conocida como WinG pero no tuvo la aceptación esperada y los buenos juegos siguieron corriendo en Modo Protegido desde MS-DOS con ayuda de los Dos Extenders. Sin embargo, un poco mas adelante, Bill Gates finalmente aceptó que la única manera de lograr que los buenos juegos fueran desarrollados para Windows era dándo un acceso mucho mas DIRECT-o al hardware.

Inicios del DirectX.

Antes de entrar en detalle, hay que explicar primero el concepto de Overhead. Como en su origen las computadoras personales tenían muy pocos componentes realmente estandar aparte de un CPU Intel o compatible, era muy común crear capaz de delegación intermedia para facilitar la comunicación entre los dispositivos mas dispares sin cambiar los códigos originales. Por ejemplo, en tiempos del DOS, si uno quería escribir un pixel en pantalla primero tenía que llamar una función de la biblioteca de gráficos de C llamaba BGI(o cualquier otra biblioteca de gráficos) llamada putpixel(); que recibía las coordenadas X, Y y el color. Esta a su vez llamaba al sistema operativo para dar la órden de pintar el pixel, luego el sistema operativo llamaba al BIOS que ejecutaba la interrupción 10h y luego de hacer una complicada y tardada serie de validaciones al fin escribía el mentado puntito de color en la pantalla. Este proceso era tan lento que uno podía hacer un ciclo anidado para pintar la pantalla y podía ver como esta cambiaba de color lentamente. ¡Y pintar una pantalla completa de 320 por 200 tardaba casi un minuto!. Sin embargo, con ensamblador bastaba con conocer la posición de la RAM de Video y escribir un pixel era tan rápido como mover un byte a una posición de memoria. Eso sin contar que existían muchos recursos para manejar la tarjeta de video para hacer animaciones rápidas (de momento recuerdo por lo menos tres). El asunto era como dar acceso a los programadores a esta velocidad sin necesidad de salir del Windows. Y fue así como nació DirectX

Como su nombre lo indica, la idea original tras el DirectX era darle a los programadores el acceso mas directo posible al Hardware sin comprometer la protección de memoria del propio Windows. Mientras que intentaban ahogar los problemas de compatibilidad de hardware con capas de abstracción y emulación de hardware. Al principio DirectX fue un fracaso, pero no tanto porque fuera una mala idea, sino porque la mayor parte de los recursos del sistema estaban siendo usadas por el resto de las aplicaciones. No fue sino hasta la aparición del DirectX 5 que se empezaron a ver juegos para Windows mas o menos decentes. En ese entonces, los juegos de 32 bits soportados en los DOS Extenders ya comenzaban a oler a muerto.

C:\RUN\DOS\RUN>

Los vaqueros del viejo oeste solían decir que no había mejor indio que el indio muerto, y yo digo que el mejor de todos los Windows fue el Windows 98 SE, pues permitía explotar un sistema Pentium III a plena capacidad con todo y sus puertos USB en menos de 30 megas. Además de ser muy estable y ser el último que tenía la opción de reiniciar en Modo MS-DOS. Con un sistema como este fue que mi grupo de desarrolladores renegados aprendimos una buena cantidad de cosas sobre computación. Sin embargo. Sin embargo, con la llegada del temido Windows NT y sus derivados a las computadoras caseras, esta maravillosa era terminó. No mas juegos de 32 bits que tomaban el control absoluto del sistema. De hecho, en esa época, mientras jugaba el juego Hexen en una PC Pentium III con Windows ME apareció una pantalla sobre un error en algo llamado WinOldAp. De acuerdo con una poca de investigación, Winoldap era un servicio del sistema operativo que permitía correr aplicaciones de la época descrita en la entrada anterior “Revolución de 32 Bits” en este caso me enteré de que estaba muerto hasta que el mismo Windows me lo había informado.

…llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras…

Por cierto, y hablando del Windows ME, fue a partir de esta versión del sistema operativo de Micro$oft que la feliz armonía entre el Windows y los programadores de juegos que usaban Dos Extenders (o que entraban al modo protegido por su cuenta) se acabó. A partir del Windows 2000 y el ME ya no había manera de salirse del Windows y tomar el control absoluto del sistema como antes. Recuerdo que hubo una pequeña guerra entre mi grupo de amigos programadores por que sistema instalar en nuestras computadoras. Pues un sistema posterior al Windows 98 no nos permitía programar como lo habíamos hecho hasta entonces. Y la peor parte es que todas las herramientas para desarrollo en Windows eran inadmisibles dados nuestros métodos de trabajo. Llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras por lo que, como abandonar la programación en ASM no era una opción decidimos hacer lo mejor que se nos ocurrió: ¡Programar en Ensamblador para otras plataformas! Aunque eso significara crear la nuestra propia.

Y en ese entonces fue cuando se dio nuestro destierro de la programación en Ensamblador para computadoras caseras. Aunque en ese tiempo hicimos muchos avances en otras áreas relacionadas con el Ensamblador que se mencionarán en la siguiente entrada. Pero eso no nos salvó de experiencias terribles que poco a poco fueron debilitando al equipo aunque sin llegar a acabar con él por completo.

En la siguiente entrada se contará de que fue de la programación en Ensamblador (o al menos la parte que me tocó vivir) durante los primeros años del presente siglo y como gracias a los esfuerzos de grandes hackers como Iczelion y otros cuyos seudónimos no alcanzo a recordar los programadores de Ensamblador pudimos regresar a la escena de la computación casera de la que alguna vez nos sentimos desterrados. Pero entre ese tiempo, muchos de nosotros nos convertimos en poco menos que vagabundos y esos oscuros años son los que se narrarán mas adelante.

Revolución de 32 Bits

–Y la Lenta Muerte de los Sistemas de 16 Bits–

Quienes han entrado a la Red Social de Programadores de Ensamblador de seguro han leido los escritos de b1ackpig sobre el formato PE. Para quienes no sepan de que hablo, PE o Portable Executable es el formato de los programas de aplicación del Windows. En esos documentos se hace referencia a un importante evento histórico ocurrido en la década de los noventas: “La Transición del DOS al Windows”. Aunque detrás de todo esto se hallaba la verdadera transición de la programación de 16 a 32 bits. Veamos primero un poco de historia…

Desde que Intel inventó el procesador 8086 e IBM lo adoptara para construir su famosa IBM-PC, la tecnología de los 16 bits era el estandar de las computadoras de sobremesa, en esos tiempos los sistemas de 8 bits eran poco menos que consolas de videojuegos y los de 32 bits solo podían hallarse en costosas computadoras dedicadas a la investigación. Sin embargo, todo cambió alrededor de 1985 cuando Intel desarrolló el procesador 80386. Esta paqueña maravilla era capaz de hacer todo lo que en su tiempo solo podían hacer las grandes computadoras de los centros de investigación. Sin embargo, dado que era un procesador muy avanzado no había una plataforma de hardware que lo aprovechara a su pleno potencial y de haberse construido hubiera sido sumamente costosa. Como muestra, la primera computadora de escritorio equipada con este CPU llegó a costar ¡10,000 DOLARES!

Debido a esto, no fue sino hasta los últimos años de la década de los ochentas que las computadoras para civiles con CPU’s de 32 bits llegaron al mercado de masas. Sin embargo, al igual que el 286 que bien podría considerarse un mal prototipo del 386 (modo protegido de 24 bits, registros de 16 y problemas de compatibilidad hacia atrás), estas poderosas computadoras de 32 bits seguían siendo programadas como el viejo 8086. Mas adelante, con la llegada del 486 de Intel comenzaron a verse algunos sistemas que rebasaban el megabyte en RAM. Y entonces fue cuando realmente comenzó la guerra por la optimización.

Si ustedes tienen o superan los treinta, de seguro recordarán una época en que había juegos(sobre todo de Lucasarts) cuyo ejecutable media alrededor de 500 kbytes y que al tratar de correrlos en una 486 con 4 megabytes en RAM, aparecía un mensaje que decía “NOT ENOUGH MEMORY”. ¿Como era posible que una PC recien iniciada con 4 mbytes en RAM no pudiera correr un pinchurriento jueguito que no medía mas de medio mega? La razón de esto era porque estos programas estaban hechos para correr en Modo Real.

Modo Real

Este era el modo de operación por defecto del antiguo CPU 8086. En el se tenían registros de 16 bits, se usaban 20 bits para manejar la memoria. Con 20 bits es posible tener control sobre apenas un megabyte en RAM que son aproximadamente 1,048,576 bytes (100000h en hexadecimal). De estos pocos mas del millón de bytes, solo 640kbytes estaban a disposición de los programas. El resto pertenecía a la memoria de video, llamadas al sistema operativo, vectores de interrupción y hasta unos ROMS fosilizados que estaban ahí desde los tiempos del CP/M (el antepasado no reconocido del DOS). Además, de esos 640 kbytes, ya algunos estaban ocupados por servicios del sistema operativo. De hecho, y nada mas para insultar, este es el ensamblador que aún en este siglo XXI se imparte en buena parte de las carreras universitarias de Ingeniería en Computacion. La pregunta era: ¿Donde estaban los programadores capaces de entrar al Modo Protegido?

En realidad ya existían programas de 32 bits para computadoras personales desde fines de los años ochenta para computadoras basadas en CPU’s 386 o superiores. Un ejemplo era el no tan famoso sistema operativo OS/2 de IBM del cual se dice Bill Gates robó todo lo que no pudo encontrar en la GUI de las computadoras de Apple. La razón por la que el OS/2 no tuvo el éxito esperado era porque no tenía suficiente compatibilidad hacia atrás con el software existente de 16 bits que corría en la inmensa mayoría de las computadoras personales con DOS y las primeras versiones del Windows de 16 bits.

Primeros juegos de 32 bits para PC

Ya entrados los noventas, cuando el estandar eran las PC con CPU 486, DOS y Windows 3.1 ocurrió un fenómeno muy interesante: ¡Aparecieron juegos que rompieron la barrera del mega en memoria! La razón era sencilla. Los programadores habían descubierto la manera de entrar al Modo Protegido desde el DOS. Con esto tenían acceso a toda la memoria del sistema y a los registros de 32 bits. Los mas experimentados entraban por ellos mismos pero también había algo llamado DPMI (Dos Protected Memory Interface) que permitía tener acceso al direccionamiento de memoria de 32 bits desde una “sencilla” aplicación en DOS. Lo de sencilla lo pongo entre comillas porque no era nada facil de hacer. Y como han de imaginarse, los primeros que abandonaron el primer Megabyte de RAM fueron precisamente los que sabían programar en Lenguaje Ensamblador.

Mas adelante apareció un compilador que no solo trabajaba en 32 bits. ¡Sino que además era de uso libre! Llamado DJGPP. Gracias a este compilador y a DPMI’s como el famoso DOS4GW surgieron las grandes leyendas de los juegos de PC de mediados de la década de los noventas. Aunque aún era necesario saber algo de Ensamblador para acelerar algunas rutinas gráficas y mantener la memoria bajo control. De hecho, esta pantalla de advertencia era la que nos decía que el juego a cuyo ícono habíamos hecho doble click iba a ser genial:

Y esta era fue precisamente la que nos tocó a mis amigos y a mi. Los tiempos de las primeras computadoras con un CPU Pentium con FPU integrada, las primeras versiones del Windows 95, las conexiones telefónicas a Internet facturadas por hora y la fiebre de los First Person Shooters. Poco antes de que el Software Libre se pusiera de moda y la única manera de hacer trabajar una PC armada con componentes chinos era instalando copias piratas del Windows que circulaban en cajas de Floppies de 3.5 pulgadas. Y la herramienta mas avanzada de desarrollo de software era el Borland Turbo C++ 3.0 (cuya licencia costaba 500 dólares mas impuestos en tiendas especializadas de informática). En ese entonces intentamos hacer juegos programados en C/C++; pero pronto llegamos al límite del compilador, pues al ser un compilador de 16 bits para DOS no nos permitía manejar mas de un megabyte de memoria ni era facil escribir a la memoria de video. A la fecha no se me olvida lo complicado que era hacer un frame buffer usando las funciones de memoria malloc( ) y free ( ). O new( ) y delete ( ) en C++ o modificar la tabla de los vectores de interrupción para el teclado y el reloj interno del sistema sin que el sistema completo se hiciera porquería. Por estas razones, pero sobre todo por la de manejar una mayor cantidad de memoria es que se decidió que había que programar en ensamblador.

Al principio hacíamos programas en C y compilábamos por separado rutinas de Ensamblador que era posible llamar desde C cual si se tratara de funciones de la biblioteca estandar; al principio esto funcionó bastante bien pues teníamos la “facilidad” de programar en C/C++ combinada con la velocidad y control de las rutinas de Ensamblador. Hasta que notamos que los códigos fuente lo único que conservaban de lenguaje C era solo el main( ) y las { }. ¡Todo lo demás eran puras llamadas a rutinas hechas en Ensamblador! Así que decidimos que era el momento de quitarle las ruedas de entrenamiento a las bicicletas y programar todo en Ensamblador de una vez por todas. ¡Los resultados fueron sorprendentes! Pues programas completos que medían alrededor de 200 kilobytes en C, en ensamblador no ocupaban ni la centésima parte de eso y los errores de desbordamiento y tipo de datos eran rarísimos. En ese entonces trabajábamos con la misma copia pirata del Borland Turbo Assembler que aún circula en muchas universidades de países de centro y sudamérica. Y como ya han de imaginarse, este ensamblador aunque ya podía trabajar en 32 bits no estaba preparado para los grandes avances que se veían venir como por ejemplo la tecnología de Intel MMX. Y aunque es posible programar en ceros y unos (y llegamos a hacerlo) esto era demasiado tardado. Por lo que nuestro siguiente gran reto fue programar nuestro propio compilador de Ensamblador.

Sin embargo, durante la extensa investigación sobre como hacer un compilador propio (y verdadera investigación, no las jaladas sobre “teoría de autómatas” que tanto han desprestigiado las universidades chafas) el buen b1ackpig dio con un interesante descubrimiento: el FASM.

El FASM o Flat Assembler es el mejor compilador de ensamblador que he encontrado y es el que he estado usando hasta el día de hoy. Pues tiene casi todo lo que un programador puede necesitar: (Es libre, posee muchas herramientas, casi no consume recursos, se actualiza muy rápido y tiene muy buena documentación) Hablar de las maravillas del FASM merece su propia entrada en este blog. Sin mencionar que el paquete incluía su propio código fuente en Ensamblador. Yo personalmente aprendí mucho leyendolo. En fin, en esa segunda mitad de la década de los noventas, b1ackpig, el Julio y yo teníamos a la computadora lo suficientemente dominada para programar un verdadero juego de video. Solo faltaba un poco de Programación Gráfica, que en nuestro caso se resumía a simple álgebra lineal y geometría diferencial de libro de texto para hacer verdaderos juegos 3D.

Pero a finales de la década de los noventa ocurrieron unos cambios radicales en el mundo de la computación que nos metieron en serias dificultades; eso mas unos serios errores tácticos que cometí relacionado con la programación gráfica en Windows que retrasaron nuestras investigaciones por años. Eso sin contar que por ese tiempo fue cuando me expulsaron de la universidad. Pero eso es una historia que será contada en la siguiente entrada de este blog.

Mercado de Sueños y Pesadillas

–El Drama de los Artistas Digitales–

Acabo de regresar de la Convención de Historietas organizada en Cintermex en Monterrey. A veces pienso que si llego a desarrollar algo que valga la pena este tipo de eventos son el mejor lugar para mostrarlo. Pero antes de decir todo lo que vi ahí, quiero contarles una pequeña historia acontecida uno o dos años antes de que tomara la decisión de convertirme en programador de Lenguaje Ensamblador…

Primero, tengo que declarar que si hubiera nacido en una era donde no existieran las computadoras, definitivamente me habría convertido en escritor. De hecho soy hijo de un cierto novelista frustrado y tengo algunos primos del lado paterno (uno de las cuales niega su propio apellido) que han escrito unos cuantos ensayos y raquíticos libros de poemas. Sin embargo, la razón por la que no quise ser escritor es que en latinoamérica todos los intelectuales están metidos en política y viven hablando mal del mismo gobierno que les da becas y programas para el “fomento de la cultura” para que no se mueran de hambre. Sin mencionar que la mayor cantidad de dichos libros son puros escritos intelectualoides que nada mas leen los mismos 3 o 4 ancianos hipiescos de siempre y el resto no son mas que panfletos de superación personal con mensajes culpígenos y pseudo-religiosos. Por eso decidí que el mejor medio para contar mis historias era a traves de un buen juego de video y el mejor lenguaje para esto es el Ensamblador.

Mi (no muy buena) experiencia en el mundo del Comic

Bueno, tras este preámbulo ahora va la historia: Resulta que en mis años de preparatoria yo realmente quería ser escritor; pero por lo contado arriba decidí buscar una opción mucho mas comercial. Un amigo de aquel entonces tenía una hermana que era entintadora en un grupo que hacía historietas y fue por medio de este contacto que me acerqué a ese mundo. En esos tiempos fui a las primeras convenciones de juegos de mesa y comics organizadas en Cintermex. En ese ambiente vi lo típico a lo que se enfrenta la gente que se dedica al ‘arte comercial’. Peleas con los editores, discusiones por los recursos económicos; divisiones por ideas y lo mas divertido de todo, las peleas con dibujantes rivales.

Que puedo decir, creo que el mejor término que puedo usar para designar a estos artistas es el de dibujantes, pues era lo que mejor hacían. Aunque uno de ellos era guionista-escritor. De hecho solo éramos 2 escritores y yo no pasé de corregir faltas de ortografía de un par de cuartillas. Y aunque era un grupo mas o menos numeroso, yo solo recuerdo haber tratado con tres de estos artistas de manera mas o menos constante: he aquí algunos de ellos y escribo sus nombres por si alguien los conoce…

Francisco Pineda: Dibujante de aspecto reservado y con fuertes influencias de los comics japoneses. A pesar de ser uno de los artistas mas importantes de aquella organización (y quien mas me inculcó el odio hacia cierto dibujante rival) no supe que fue de su carrera artística. Lo último que escuché de él es que entró a trabajar en Agua y Drenaje de Monterrey y no precisamente dibujando los promos publicitarios. Se dice que su novia (de entonces), quien también era dibujante, si logró publicar un par de tiras en uno de los periódicos locales y a la fecha, por una búsqueda que hice en el google, parece que da clases de dibujo en una pequeña escuela de arte.

Jose Luis “Abril”: Este era el típico artista intelectual de cabello largo y caracter dificil. Otro buen dibujante que se decía era hijo de un pintor al que por mi escasa preparación intelectual no conozco su obra (aunque llegué a estar parado en medio de su estudio). Este era el mas interesado en hacer arte para videojuegos y estába en pláticas con él para integrarlo en un grupo de desarrollo de videojuegos hasta que en una reunión uno de mis secuaces (el Julio) se emborrachó e hizo un pleito memorable en casa de su inestable novia. Por no contar el “Incidente Rococó” del que el propio Julio puede hablarnos en los comentarios. Por cierto, me encontré a este artista en una convención de historietas posterior a ese incidente. Ya había cambiado de novia y veía el asunto como un incómodo recuerdo. Me pregunto si aún se dedicará a dibujar o ya habrá tomado un trabajo de adulto responsable.

Arturo Vega: Un mulato de considerable estatura y tono de voz tan alegre como imponente. Este era el otro escritor y por cosas que me contó parece que si llegó a elaborar el argumento de un par de revistas de historietas. Vagamente recuerdo una historia de un esgrimista greñudo, un nerd que se había condenado al infierno por ver no se que cosas y una rubia cuyo nombre era un juego de palabras medio gótico. Decía sentirse un poco relegado por los dibujantes. Lo último que supe de él fue que formó una familia e intentó incursionar en la animación digital. Por cierto, en cierta época hubo un programa de radio de historias de terror escritas por aficionados y se rumoreaba que los mejores relatos de ese programa había sido escritos por él usando un seudónimo.

Ahora vamos a pasar a la parte de las peleas. Todos los que nos dedicamos a crear algo artístico tenemos un Némesis, que puede ser un artista o programador con el que queremos medir fuerzas o simplemente alguien que no nos agrada porque llama mas la atención de los medios que nosotros. En el caso de estos dibujantes, dicho personaje era un artista regiomontano que se había hecho famoso por su habilidad para dibujar patos. Y aunque su producto era de una calidad bastante superior a lo que normalmente se podía encontrar en los puestos de historietas del norte de México su estilo gráfico no acababa de gustarme. No vale la pena mencionar el nombre porque luego los buscadores pueden dar con este sitio. Pero este personaje era autor de declaraciones a los medios tan humildes como “Soy demasiado profesional para trabajar en México”. Hoy en día este ser entró a trabajar de colorista a una de esas granjas de dibujantes que tienen algunos estudios norteamericanos; pero lo que les dice los frikis mexicanos es que dibuja el solo los mejores comics de Marvel sentado en las rodillas del mismísimo Stan Lee. Creo que con este pequeño dato muchos de los que asistieron a la convención de Historietas de Cintermex en Monterrey ya sabrán de quién estoy hablando.

Por cierto, husmeando en una cierta página de internet bien conocida por dibujantes de todos los niveles y presupuestos, encontré una nota de uno de los artistas que fue a la convención. Era un poco triste ver como invitaba a los alumnos de su escuela de arte a ir a condición de que le ayudaran a pagar la renta de la mesa en el evento. La verdad es que es lamentable ver a artistas tan talentosos pasar por ese tipo de humillaciones. A veces pienso que las empresas desarrolladoras de videojuegos (en Monterrey hay 2 de ellas legalmente consolidadas pero de las dos no se hace una) podrían encontrar buenos diseñadores en esta clase de eventos, pues son artistas jóvenes con experiencia en las artes digitales. Parece mentira que al otro lado del mundo empresas de videojuegos gasten grandes sumas en contratar estudios de animación para que les diseñen sus personajes mientras que en latinoamérica hay una enorme cantidad de artistas talentosos dispuestos a vender sus obras por comida.

En fin, esa fue la triste historia de un grupo de dibujantes de historieta cuyo destino no estoy muy seguro de conocer. Y el mundo de la programación de videojuegos no es demasiado diferente de esto, salvo por el hecho de que los buenos programadores de juegos son mucho menos numerosos que los buenos artistas al menos en latinoamérica. Hasta ahora no me ha tocado ver a un solo grupo de desarrollo de juegos pasar por este tipo de penurias. ¿O será acaso que como casi no hay programadores de juegos no me ha tocado ver estas escenas?

Arte para videojuegos a precios accesibles

Por cierto, lo único de valor real para este blog que hice durante toda la proyección fue preguntarle a un artista de doblajes proveniente de Chile sobre si los estudios de doblaje se alquilan para dar voces a personajes de videojuegos. La respuesta me sorprendió, pues me dijo que no solo hay actores profesionales que prestan su voz para doblar juegos ya hechos a otros idiomas; sino que hay una gran cantidad de ‘estudios’ donde experimentados ‘voice actors’ hacen voces para juegos y animaciones nuevas. ¡Y por menos de lo que cuesta contratar a un estudio de doblajes serio! No voy a entrar en la pelea sobre si el doblaje Mexicano es mejor que el de los otros países pero también el mas caro. La verdad es que una de mis preocupaciones a la hora de desarrollar videojuegos era la del costo de contratar actores profesionales para grabación de voces y captura de movimiento. Pero si esto sigue así, puede que estos estudios sean la clave para que pequeñas empresas desarrolladoras de videojuegos puedan producir juegos con arte de buena calidad a un precio razonable para todos. Por una parte me da tristeza ver que cada vez es mas dificil que un buen artista tenga buenos ingresos; pero por otra parte no deja de alegrarme el hecho de que gracias a esto ahora hay acceso a artistas PAGABLES. Y supongo que eso también es bueno para ellos al ver ampliada su cartera de clientes.

Me pregunto si en Guadalajara o el Distrito Federal las empresas de desarrollo de videojuegos se presentan en las convenciones de Historietas o solo van a los eventos organizados por ellos mismos y los que solo van ellos y uno que otro grupo de escolares despistados enviados por sus institutos. Sea como sea, esto ya se tardó. Lo que me tranquiliza es que gracias a este blog mis proyectos ya no son delirios solitarios y realmente hay gente interesada en esta clase de desarrollos. Supongo que ahora debería de hablar de una psicosis colectiva. Por cierto, en la comunidad de programadores de ASM ya somos 9. Aunque aún le falta bastante para crecer; espero que para este nuevo año podamos hacer algo que realmente valga la pena. Por ahora es mejor programar porque a como van las cosas yo también voy a acabar de maestro en alguna escuela de programación y, si es que llego a hacer un juego, también voy a tener que pedir cooperación a mis alumnos para que me ayuden a pagar una mesa en algún evento de videojuegos.

¡Un Año de asm86.wordpress.com!

–Doce meses de programación en Lenguaje Ensamblador–

 

Pues como bien nos ha recordado b1ackpig, en este mes de noviembre del 2009 se cumple el primer año de operaciones de esta especie de blog. Aun recuerdo aquellos dias de noviembre de 2008 cuando decidí que no quería dejar morir este poderoso lenguaje. Y porque al no poder regresar en el tiempo para enseñarme a mi mismo a programar en él, quise hacer aquella página de Internet que me hubiera gustado encontrar en esos ahora tan lejanos años en los que comenzaba a programar, en espera de que otros que apenas comienzan su camino sepan al menos que hacer.

Debo de admitir que al principio no esperaba tener demasiados lectores, (hoy tengo poco mas de 100 hits únicos por día y en ciertas fechas rebasa los 240) y no me interesa demasiado tenerlos. Pues la programación en Ensamblador no es algo que se considere popular. Pero como lo contrario a lo popular es lo elitista, se que quienes leen las estupideces que escribo aquí con cierta regularidad se cuentan entre los mejores programadores, o al menos les interesa llegar a serlo algún día. No dudo que entre quienes leen esto se encuentren varios programadores mucho mejores que yo, y espero que pronto comenten para aprender de ustedes. Pero bueno, ahora que releo las entradas mas antiguas me doy cuenta de que se pueden dividir en estas categorías:

• 1.- Tutoriales para principiantes
• 2.- Peleas con lamers
• 3.- Temas mas o menos avanzados que no llevan a ninguna parte
• 4.- Notas sobre el Desarrollo de Videojuegos (y su relación con el ASM)

Además de una buena cantidad de violencia gratuita y algunos enlaces a otros recursos de programación mas o menos valiosos. Y por consejo del buen b1ackpig, he pensado en hacer una recopilación de varias notas (si no es que de todas) en un PDF, pero sería mas que un Copy-Paste. Pues ahora que tengo mas de 100 entradas con sus casi 300 comentarios ya puedo hacer algo que valga la pena. Ese PDF se dividiría en 4 partes, la principal sería un manual de programación en Ensamblador, la otra serían los temas sobre ensamblador que son demasiado avanzados para un simple tutorial o que no se detallan lo suficiente para explicarlos. Y la tercera sería la sección que bien podría llamarse “Ahora a insultar” y abarcaría todas las notas sobre las peleas con lamers y demás peripecias y batallas épicas libradas en este blog. El tema del desarrollo de videojuegos en realidad quedaría repartido en estas 3 primeras secciones (tutoriales detallados, temas a discusión y desde luego las épicas peleas con otros autodenominados “profesionales de la industria” de los videojuegos que me he topado en internet). Por último, la cuarta parte sería el verdadero contenido original del libro. Y ahí escribiría todo lo que no se hubiera dicho en los 3 capítulos pasados.

Si esto va bien, podría hacerse cada año no solo para festejar sino a modo de recopilación mas o menos usable. Pero esto, si es que se llega a hacer va tomar un tiempo y saldrá hasta ya entrado el mes de diciembre de este 2009.

Ahora la cosa es discutir un poco sobre el futuro: pues ya este proyecto comienza a tomar forma. He pensado en muchas cosas, una de ellas es la de hacer un podcast para que aquellos que por cualquier razón no pueden estar demasiado tiempo frente a la pantalla puedan seguir informándose sobre la programación en Ensamblador. Otra cosa que me urge hacer es comenzar el tema de la programación gráfica en Ensamblador, pues recientemente me he topado a un par de “Investigadores” del tema que la verdad… bueno, por ahora estoy de muy buen humor como para ponerme a insultar. Pero como ustedes ya saben una de las cosas que mas me enfurecen de esto de la programación es que gente que no sabe hacer otra cosa que scripts para un engine o llamadas a una API reciba trato de “Profesionales de la Industria” mientras que otros que genuinamente les interesa programar tienen que dejar de hacerlo y acaban administrando bases de datos por comida. Lo bueno es que a la par que este blog, la gente que lo visita ha cambiado mucho, ya casi no vienen lamers y quienes comentan dicen cosas cada vez mas sensatas e interesantes para todos los otros que les interesa programar en ensamblador.

Una cosa que si quiero hacer es poder reunir a todos los programadores de Ensamblador que pueda sean jóvenes aficionados que apenas comienzan o viejos hackers locos que no quieren tirar su 486, y trabajar todos juntos en algunos proyectos que solo en ensamblador pueden hacerse a un nivel respetable. Por ejempo gráficos en tiempo-real, desarrollo de juegos de última generación o cualquier cosa de ese mismo calibre. Como ya han de imaginarse mis fines no son nada pacíficos, en realidad quiero formar un equipo para jugar algunos “partidos amistosos” con otros grupos de “desarrolladores” con los que quiero medir fuerzas. Pues lo mejor que me ha dado este blog es que me ha mostrado que no estoy solo en esto de la programación en ensamblador y que ahí afuera hay otros, no muchos, que se sienten igual. Estoy seguro de que si nos organizamos y trabajamos juntos podremos crear grandes proyectos que puedan desafiar tecnológica y económicamente a los autodenominados “profesionales”. No estoy muy seguro en otros países; pero al menos en México y buena parte de latinoamérica hasta ahora no ha aparecido ninguno de estos que pueda competir contra un grupo de buenos programadores de Ensamblador bien organizados. Estoy seguro de que si trabajamos juntos podremos hacer grandes cosas, y por grandes cosas quiero decir grandes cosas a nivel económico.

No va a ser nada facil; pero programar en Ensamblador tampoco lo es. Vienen cosas impresionantes; pero también tiempos difíciles que van a requerir un gran esfuerzo para quien quiera participar. Pero por ahora festejemos y procedamos a comernos este pastel que espero realmente sea de chocolate.

Modo Protegido

–O el Hotel de los OpCodes Rotos–

 

Una de las cosas mas importantes que tienen los nuevos sistemas operativos respecto a los antiguos es la capacidad de hacer que muchas aplicaciones trabajen de manera simultanea en computadoras que tienen un solo CPU. En otra nota hablaré sobre como demonios hace el sistema para hacer esto; pero ahora quiero responder a una pregunta mucho mas interesante: ¿Como demonios le hace el sistema para que miles de programas corran de manera simultanea sin hacerse porquería unos a otros? La respuesta es precisamente en lo que Intel ha dado en llamar el Modo Protegido.

¿Y que demonios es el Modo Protegido? Se trata de un mecanismo de seguridad jerárquica mas o menos complejo implementado en el propio CPU. Gracias a él es no solo es posible correr muchos programas simultaneamente, sino además de que se logra que cada uno se comporte como si tuviera toda la computadora para él solo. Este sistema se basa en cuatro niveles de prioridad que a menudo se representan como anillos concéntricos donde quien está mas al centro tiene poder sobre los que están mas a la periferia. Pero como esto me parece muy complejo y aburrido como para explicarse en este blog voy a hacer una analogía mas comprensible para (muy pocos de) ustedes: Un Hotel

Un hotel es el perfecto simil de un sistema operativo que corre en Modo Protegido como lo hacen Windows y Linux en su versión x86. Pues en ambos se tiene a un montón de gente (los programas) cohabitando en un mismo espacio mas o menos grande. En el lugar mas bajo de la jerarquía tenemos las habitaciones de los huéspedes. Se supone que cada huesped puede usar una habitación por la cual pagó y nadie puede entrar a una habitación que no sea la suya, al menos no sin el consentimiento de quien está adentro. Cuando la habitación se desocupa esta puede ser usada por alguien mas sin afectar por ello la vida en el resto del hotel. En un sistema en Modo Protegido, una aplicación que es cargada recibe un espacio dentro de la memoria y tiene acceso (o eso es lo que ella cree) a muchos recursos comenzando por un espacio de memoria exclusivo que ninguna otra de las aplicaciones puede leer o escribir (salvo por un error en la función VirtualProtectEx pero eso es otro show). En caso de que una de estas aplicaciones termine su ejecución o peor aún falle y deje de funcionar el sistema no se ve afectado por ello.

En el siguiente nivel de esta jerarquía están los servicios comunes como el comedor, la piscina (eso si la piscina no está cerrada),el gimnasio o cualquier otra area similar. Los huéspedes pueden hacer uso de estos recursos ya sea turnándose o reservando un lugar con anticipación. De este modo, aunque se tenga únicamente una piscina (y si no está cerrada) todos pueden ir a nadar sin temor a que nadie se apodere de esta para él solo. En el Modo Protegido es igual. Todas las aplicaciones pueden hacer uso de los recursos del hardware como discos, pantalla, puertos de comunicaciones o archivos pero para hacerlo tienen que pedir permiso al sistema. Ninguna aplicación puede acceder de manera directa a estos recursos sin desencadenar el temible Fallo de Protección General. Pero puede hacer uso de los servicios de los controladores o Drivers para beneficiarse de esos recursos. Pasando de nuevo a la analogía del hotel, los empleados que dan acceso a estas instalaciones son los controladores de dispositivo.

El segundo nivel mas alto de la jerarquía dentro del hotel lo tiene el personal e instalaciones de mantenimiento. Inmediatamente arriba del personal que da acceso a las instalaciones comunes tenemos al resto del personal del hotel. Entre los que destacan el personal de limpieza, los que asignan las habitaciones a los nuevos huéspedes, los encargados de hacer reparaciones cuando algo se descompone y en general todos aquellos que mantienen el hotel de una sola pieza. Como ya se sabe el personal de mantenimiento tiene acceso a casi todas las areas del hotel como por ejemplo las habitaciones de los huéspedes a los que entran para limpiarlas de vez en cuando. Sin embargo los huéspedes no pueden entrar a instalaciones tales como las oficinas administrativas, las áreas tras los mostradores, la cocina del hotel o al cuarto de máquinas de la piscina (en el caso de que la piscina no esté cerrada). En el Modo Protegido este nivel corresponde a los mas importantes servicios de sistema como por ejemplo el control de la Memoria Virtual, la asignación de espacios dentro de la memoria física, la conectividad de red, el control de ejecución y cambios en el modo de operación, o el manejo de errores y excepciones. Dependiendo de la complejidad del sistema esta parte puede corresponder al nucleo del sistema operativo o estar fuera pero trabajar de modo estrecho con este.

En el nivel mas alto de la jerarquía está el dueño del hotel, el típico gordo sudoroso y sin camisa que se pasa el día espiando a los huéspedes a traves de un complejo sistema de cámaras ocultas tras los espejos de los baños y en las lámparas de techo. Este ser maneja el hotel completo desde su silla mantecosa y decide (dependiendo de lo que ve con sus cámaras) cosas como por ejemplo quién se queda o se va del hotel, se encarga de vigilar de las instalaciones funcionen correctamente y de no ser así mandar al personal de mantenimiento a arreglar las cosas. Por ejemplo, si la piscina tiene SIDA, mandar cerrarla. O evitar de que un grupo de huéspedes con cabello afro la cierren. En pocas palabras, el dueño del hotel es quien tiene control absoluto sobre todo y sobre todos. Supongo que no tengo que explicar demasiado su equivalente en el Modo Protegido. En el anillo de protección de mayor jerarquía, también conocido como el Anillo Cero o “Ring 0” es donde se encuentra el nucleo del sistema. Este nucleo se encuentra en lo mas alto del poder respecto al resto del sistema, sino que tiene acceso directo a muchos servicios privilegiados de la propia computadora que solo desde este anillo de protección es posible manejar sin desencadenar un Fallo de Protección General.

Y bien solo queda por contestar una pregunta: ¿Y que pasa si alguien desobedece estas leyes de protección? La respuesta es el temible General Protection Fault.

General Protection Fault (Fallo de Protección General)

Uno de los errores mas comunes en la era del Windows 95 esa el famosísimo General Protection Fault. Este ocurría cuando una aplicación intentaba invadir un espacio de memoria que no era el suyo o cuando ejecutaba una instrucción de CPU que estaba por encima de su nivel de privilegios. Cuando el Procesador detectaba esta situación generaba la “Exception 0D General Protection Fault”. No se si será coincidencia pero a esta excepción le corresponde el número de mala suerte por excelencia en el mundo occidental, el 13. A grandes rasgos, una “Exception” es un código que se dispara cuando el CPU detecta una condicón peligrosa determinada de antemano. Se supone que en un sistema bien hecho una excepción es como una alarma contra incendios que detecta el fuego y activa los aspersores automáticos para apagarlo y una vez hecho esto regresar a la ejecución normal. Pero en los tiempos del viejo Windows 95 la única manera de salir de una General Protection Exception era reiniciando la computadora.

Otra nota curiosa es la de porqué son exactamente 4 niveles de protección dentro del Modo Protegido. Al parecer 4 era la potencia de 2 mas cercana al 3, pues como todo jefe sabe para manejar a la burocracia se necesitan cuando menos 3 niveles en la jerarquía, donde el mal alto corresponde al jefe y el mas bajo a los que hacen el trabajo manual. El nivel intermedio existe para delegar responsabilidades y encontrar culpables cuando algo falla. De hecho se dice, aunque no lo he comprobado por flojera, que las primeras versiones de Windows de 32 bits solo usaban 2 niveles de seguridad, el mas alto para el nucleo del sistema operativo y el mas bajo para las aplicaciones y que además usaban todos los descriptores de segmento inicializados en la posición cero de la memoria y con un límite de 4 Gb.¡En una época en la que las computadoras mas costosas no pasaban de los 64 megabytes en RAM.! Este diseño hacía que se produjeran muchos fallos de protección general, porque los segmentos de código de los diferentes programas en realidad quedaban unos sobre otros. La explicación de lo que es un descriptor de memoria vendrá en otra nota pero antes quiero dejarlos con algo para pensar:

Todos sabemos que los hoteles no solo se usan para hospedar parejitas, sino que a veces se alquilan para eventos especiales como convenciones, presentaciones de productos nuevos, viajes de negocios (este es el uso mas cercano al original) y algunos eventos deportivos o culturales. De hecho, la inmensa mayoría de las personas que leen este blog por gusto, las mas de las veces hemos han estado en un hotel por cuestiones de trabajo las mas de las veces. Bueno, hay quien hace de lo otro un trabajo pero eso ya no es programación. Ahora la pregunta es ¿Qué tal si para alguno de estos eventos se necesita reservar una instalación completa? Como por ejemplo, cerrar la piscina para organizar una competencia de natación, u organizar un banquete exclusivo en el restaurante del hotel o quizas llevar a cabo un concierto o baile en los jardines. O cualquier otra situación donde se necesite acceso DIRECTo a una determinada instalación.

Les dejo de tarea pensar en esto, pues esa es la clave para programar buenos videojuegos en Windows.

Test Your Might!

–¡Quien Crea Saber Programar que lo Demuestre!–

Durante la época de las arcades de inicios de los noventas, particularmente con los juegos de Mortal Kombat, podía verse un interesante fenómeno entre algunos de los jugadores: algunos ocultaban los movimientos de sus manos con su propia ropa. Al principio pensé que lo hacían para evitar que los dedos se les enfriaran en climas invernales pero esto también ocurría en días calurosos. A veces junto con el jugador principal había un “padrino” que se encargaba de cubir los controles con su propio cuerpo en ciertos momentos clave, particularmente a la hora de hacer los “Fatalities”. A la fecha soy incapaz de entender el porqué de esto; pero luego escuché otra historia que tiene mucho que ver con el asunto. Por cierto, la frase “Test Your Might!” viene precisamente del juego de Mortal Kombat.

Hace ya algunos años cierto maestro me contó una interesante historia de algo que a la fecha no se si se trata de un acto de egoismo, mentiras o simples ganas de fastidiar. Según me contó durante los inicios y mediados de los noventas él quiso dar un curso sobre programación gráfica. En esos tiempos el estandar de los juegos era 320 por 200 a 256 colores. El famoso Modo 13h en el que corrían la inmensa mayoría de los juegos de aquellos días tan lejanos. Quien me contó esta historia decía que cada vez que tocaba el tema de la programación gráfica todos los alumnos permanecián en un silencio nervioso. Cuando pregun\te a que creía que se debía esto, esto fue lo que me contestó:

–”Es que la mayoría no sabía de lo que estaba hablando y los que sabían algo no lo querían decir”–.

“¡Y los que sabían no lo querían decir!” Esta frase se me quedó muy grabada al escucharla, aunque por mucho tiempo después me encontré con situaciones parecidas en toda “la industria” de la computación. Ya perdí la cuenta de las veces que me topé con supuestos profesionales que juraban y perjuraban haber trabajado en grandes proyectos informáticos de talla internacional, desde simples administradores de bases de datos que hablaban por horas y horas de certificaciones hasta un gordo que afirmaba haber programado para la NASA (esta historia ocurrió en una plática con el grupo de usuarios de Linux en Monterrey y este personaje era el padre de un pelado que se parecía a Toru Tanaka). Sin embargo, cuando quería preguntarles acerca de su trabajo y sus descubrimientos todos guardaban silencio y se defendían diciendo cosas como que habían firmado contratos NDA que les impedían hablar del asunto u otros que sencillamente me contestaban con “que ( H!N6@D05 te importa”. La verdad es que, con el tiempo descubrí que la inmensa mayoría de esta gente en realidad era incapaz de hacer aquello que afirmaba poder hacer y de los pocos que realmente habían hecho algo, en realidad eran cosas poco menos que insignificantes. La pregunta aquí es ¿Qué es lo que la gente gana con esto?

Entiendo perfectamente que cuando alguien consigue un logro quiera que todo mundo sepa que lo hizo y como. Como los que presumen sus hazañas o sus conquistas en esas noches de juerga. Pero no entiendo porque alguien que quiere llamar la atención sobre algo que afirma haber hecho al mismo tiempo intenta ocultar los detalles sobre el “como” lo logró. No voy a mencionar ningún ejemplo famoso porque no terminaría nunca. Pero sigo yo preguntándome el porqué de esto. Mi simple lógica me dice que alguien orgulloso quiere que todo mundo vea su obra hasta el mas mínimo de los detalles para que todos se admiren de su capacidad y conocimientos. No tiene sentido que alguien así quiera ocultar precisamente este tipo de cosas.

A veces pienso que este “miedo” puede tener 2 razones: la primera es que en realidad quienes intentan ocultar esta clase de información en realidad son farsantes que en realidad no saben programar y la segunda es que tienen miedo de que alguien “les robe la idea”. El primer punto no tengo necesidad de discutirlo; pero el segundo vale la pena dedicarle un par de párrafos.

Cangrejos a 10 centavos la docena

Se dice que el escritor de la novela DUNAS (DUNE para los fans) dijo alguna vez que las ideas sin desarrollar valían 10 centavos la docena. Una idea solo tiene valor a partir de que uno le invierte el suficiente trabajo y por lo tanto, solo una idea completamente desarrollada puede considerarse robable.

La pregunta es ¿Cuanto desarrollo necesita una idea para ser considerada robable?¿Puede uno realmente decir que la idea que tiene le pertenece realmente a uno?

De hecho, recientemente acabo de terminar de ver un interesante video de una conferencia impartida en el Campus Party (y cuyo enlace pueden encontrarlo en la red social asociada a este blog) donde un empleado de Electronic Arts hablaba de lo que siempre hablan en esta clase de conferencias; mas adelante escribiré una nota completa sobre este video; pero lo que viene a colación con lo tratado en esta nota fue la última parte donde se hablaba del trabajo en equipo. Como de costumbre mencionó aquella fábula de los cangrejos en los que estos se impiden mutuamente la salida del barril donde se hallan atrapados. ( Como paréntesis, cada vez que escucho esta historia me pregunto como es que hace el último de los cangrejos para salir del barril cuando se ha quedado solo ).

Para nadie es un secreto que yo soy muy poco colaborativo para con mis colegas de “La industria”, pues aunque aún (noviembre 2009) no tengo una S.A. Registrada bajo mi nombre si tengo ya un buen rato investigando en “el mundillo” (como dirían los españoles). Yo mismo he declarado unilateralmente la guerra a determinados grupos de “Desarrolladores” y normalmente vivo burlándome de todos los demás. Pero este no es el caso cuando se trata de la Programación en Lenguaje Ensamblador; pues hasta ahora no he encontrado a un solo programador (competente) de ensamblador con el que no me lleve bien. Supongo que por el mismo hecho de que somos pocos es que existe esa hermandad innata entre los programadores de Ensamblador. Por lo que lo mucho o poco que he conseguido en mis investigaciones en estos mas de 10 años voy a compartirlo con esta comunidad.

La pregunta que supongo que han de estar haciéndose es ¿Porqué este imbecil quiere regalar por ahí sus conocimientos tan duramente ganados en lugar de usarlos para producir un buen juego y hacerse rico? Puedo contestar a esto con al menos 3 respuestas:

Primera: Estos conocimientos son exclusivamente para programadores de Ensamblador, esta información le resultará inutil, cuando no imposible de entender a quienes no conocen ni les interesa programar en este lenguaje.

Segunda: Al menos en mi país, y en buena parte de los paises mas avanzados, casi nadie programa en Ensamblador. Sin embargo ya hay grupos que dicen dedicarse profesionalmente al desarrollo de videojuegos. Si alguien se va a llevar mi empleo prefiero mil veces que se lo lleve otro programador de Ensamblador que sea mucho mejor que yo a un maldito lamer que ni siquiera sabe como hacer scripts para un motor gráfico ya hecho.

Tercera: Los trabajos “robables” son aquellos que ya están terminados, no los formados de piezas inconexas. Por lo que aunque veo muy probable que algunos hagan copy-paste con algunas rutinas veo muy dificil que alguien se tome la molestia de hacerlas trabajar todas juntas para formar un videojuego completo. Y acaso hay alguien que logre tal hazaña.. ¡Bienvenido sea al fascinante mundo de la Programación en Lenguaje Ensamblador!

Saben, desde hace ya algunos meses que quiero comenzar a hablar sobre el tema de gráficas por computadora. Pero no lo he hecho porque para poder entrar al tema se requiere de cierto dominio sobre temas de los que casi no he escrito en este blog. Pero espero poder haber cubierto algunos de estos temas y haberles mostrado como hacer una sencilla animación de sprites en uno o dos meses. Mas adelante puede que veamos algo de gráficas vectoriales. Pero por ahora es mejor velar las armas y prepararnos para lo que viene en las próximas notas.

Por cierto, la red social de programadores de ensamblador ya está creciendo, literalmente de la noche a la mañana se inscribieron “two of my most deadly minions” que me han acompañado en esto del ensamblador durante ya algunos años y el maestro que organizó el evento en el Tec de Zitácuaro. Algunas horas después entró otro famoso seguidor y casi un “contributor” que proviene de una tierra donde no es nada facil programar (él sabrá de quien hablo cuando lea esto), un programador argentino que escribe un interesante blog sobre programación tan avanzado que aún yo tengo que leerlo despacio para entenderlo y un programador español que aunque aún no ha mostrado sus habilidades ya demostró su valor al entrar a una red social de locos que solo programan en Ensamblador. En fin, espero que esa red social junto con este blog crezcan, si no con mucha gente, al menos con los mejores. Pues programar en Ensamblador es tan dificil que solo muy pocos entre los pocos pueden realmente dominar este lenguaje.

Espero que un día no muy lejano esta pequeña sociedad tenga el suficiente poder en términos de recurso humano e infraestructura de software para poder convertirse en una verdadera desarrolladora de videojuegos. Hay que actuar ahora que los esfuerzos por levantar estas empresas en México son poco menos que risibles; al menos desde el punto de vista de los programadores de Ensamblador.

Red Social de Programadores de Ensamblador

–Quienes les gusta el ASM ya no estarán solos–

Una vez mas doy mi mas sincero agradecimiento a toda la gente del Tecnológico de Zitácuaro por la conferencia de Gráficas por Computadora a la que me invitaron como expositor. Como recordarán luego de esa conferencia quedaron 2 temas en el aire: El hacer un grupo de maestros que compartan información sobre programación en Ensamblador y otro dedicado al desarrollo de videojuegos en este mismo lenguaje. A dos semanas y desde mi escondite de 8 metros cuadrados en Monterrey he comenzado una pequeña red social en NING. Aún no está terminada pero ya es mas o menos usable. Para visitarla solo den click en la captura de pantalla mostrada a continuación:

Y como de costumbre. ¿Que clase de beneficios obtendrá quien entre a esa red social? El primero es el de convivir, comunicarse e intercambiar información y códigos. Pues lo mas importante de una red social es su gente. Sin mencionar que los buenos programadores de Ensamblador son particularmente difíciles de encontrar. Y para que esta gente pueda comunicarse se dan los siguientes servicios:

Chat:

Platica en tiempo real y en grupo con todos los integrantes de la red social, entre los que destacan maestros, programadores independientes, alumnos y cualquiera que tenga algo que compartir. Parece que este chat tiene una función oculta que te permite buscar gente por su edad que aún no se como funciona. Así que si te saca plática alguien con un avatar de oso color café, di no, aléjate y cuéntaselo a quien mas confianza le tengas.

Foros de discusión:

¿Para qué discutir si podemos pelear? Participa en toda clase de discusiones relacionadas con la programación en Ensamblador, Gráficas por Computadora, Desarrollo de Videojuegos y por supuesto no podrían faltar las burlas a otros autodenominados “profesionales de la industria”. Si tienes algo que decir comienza una discusión. Aunque luego no te quejes si no puedes terminarla.

Grupos:

Para no perderse entre tanta información hay grupos interesados en un tema en particular. Ya hay uno para enseñar a los principiantes a programar en ASM y pienso hacer otros mas que se me ocurran. Si tienen alguna buena idea para un grupo no esperen y créenlo ustedes mismos.

Blogs:

Si lo que tienes que decir es demasiado para el chat y los foros de discusión, prueba el Blog. En este cualquiera que tenga la paciencia y las ideas puede escribir. Igual y puedes hasta escribir algún tipo de manual o entrada que valga la pena compartir con la comunidad.

Fotos y Videos:

Se supone que en esta sección van a ir algunos videotutoriales que aún no se me ocurre como hacer. Por favor denle buen uso a esta función y no nada mas suban imagenes del Goatse y videos de las borracheras con sus cuates.

Eventos:

Simples avisos de eventos que pueden ser usados de muchas formas, desde avisar de simples reuniones del grupo hasta dar fechas de exámenes o entrega de proyectos.

Pues que mas hay que decir. Que aunque esa red social fue pensada para los grupos de ensamblador y programación de videojuegos del ITZ cualquiera puede entrar. Leyeron bien. Cualquiera. Así que si tu que lees esto no perteneces al Instituto Tecnológico De Zitácuaro, Michoacán pero te interesa hacer programación gráfica y videojuegos en Lenguaje Ensamblador eres bienvenido.

Solo recuerda que antes de ser una comunidad ( mas ) de desarrollo de videojuegos o gráficas por computadora, se trata de una comunidad de Programación en Ensamblador. Así que si quieres hablar sobre game engines, software de diseño gráfico o, peor aún, cualquier otro lenguaje de programación que no sea Ensamblador (o C si de casualidad me encuentras ebrio o de muy pero muy buen humor) no esperes escapar con la dignidad intacta. Fuera de eso…

¡Bienvenido a la nueva comunidad virtual de Programación en Lenguaje Ensamblador!