Geek & Roll

Llegó el momento de actualizar mi PC de escritorio, y decidí morder la manzana de la tentación y armarme una hackintosh. Después de un breve período con una computadora de las llamadas “de marca” me quedó claro que lo mio no es comprar una computadora de paquete, sino armarme una a mi imagen y semejanza… o algo por el estilo. Si alguna vez les ha entrado curiosidad por saber que ocurre en el mundo de las hackintosh, sabrán que parte crucial es seleccionar hardware que sea compatible. En mi caso:

• Tarjeta madre Gigabyte H61M-USB3-B3
• Procesador Quad Core i7 3.39 GHz
• RAM 8 GB 1333 MHz DDR3
• Video GeForce GT 430 1024 MB

Y esta última parte, el video, es de lo que voy a hablar en este post. Resulta y resalta que mi tarjeta de video en realidad tiene 2048 MB en RAM, y no 1024 como lo reporta el OS. Mi instalación de OS X Lion funciona a la perfección, si no fuera por ese pequeño detalle que no me deja dormir en las noches. No puedo concebir la idea de usar solo la mitad del RAM disponible en mi tarjeta de video, aun cuando para los propósitos que la uso (que no son propósitos gamer) funcione más que aceptable. Quartz Extreme y Core Image funcionan, los efectos de escritorio son fluídos, el rendimiento es bueno.

La GT 430 en particular se supone que funciona sin modificación alguna en Lion, pero no fue mi caso. Estaba atorado en 1024×768 sin efectos de escritorio, lo cual apesta. Para esto seguí una guía en OSx86 que te explican como, mediante el uso de kexts modificados, puedes habilitar tu GT 430 pero con el pequeño inconveniente de que es para tarjetas de 1024 MB en RAM. Y si, efectivamente, mi tarjeta funciona como lo expliqué, con 1024 MB en RAM.

La cantidad de RAM se especifica en un archivo de propiedades en formato plist. Este formato está basado en XML y puede ser modificado con un editor de texto. El problema es que el formato define nodos que pareciera que están codificados con algún algoritmo. Se ven así:

<data>
BAAAAAAAAwAMAAAAAAAABwAAAAA=
</data>

El último signo = lo delata: es codificación Base64. Así que manos a la obra.

Si siguieron la guía de OSx86 para habilitar la tarjeta de video, entonces el archivo que contiene toda la configuración sobre nuestra tarjeta de video se encuentra dentro de /System/Library/Extensions/Natit.kext. Seleccionen el kext, y con la opción “Show Package Contents” naveguen a Contents/info.pl de tal manera que la ruta completa es:

/System/Library/Extensions/Natit.kext/Contents/info.pl

El archivo puede ser editado con cualquier editor de texto. Así que aproximadamente en la línea 61 se van a encontrar con lo siguiente:

<key>VRAM,totalsize</key>
<data>
AAAAQA==
</data>

Ese valor AAAAQA== de alguna manera sabemos que significa 1024, ya que es el valor que se le pasa al sistema operativo como VRAM. Para saber qué es realmente, hay que decodificarlo. En la terminal:

Cesars-Mac-Pro: cesar$ echo “AAAAQA==” | base64 -D > decoded

El programa base64 hace precisamente eso: codificar y decodificar cadenas usando base64, así que le pasamos el valor codificado y usamos la opción -D que es decodificar, finalmente la salida la guardamos en un archivo llamado decoded (para eso es el > decoded). Es necesario guardar la salida en el archivo porque la salida de base64 la da en formato ASCII, sin embargo eso no es lo que buscamos. Verán, los valores que vemos en el archivo plist son cadenas codificadas en base64, pero de datos en hexadecimal y no valores ASCII como lo interpreta la salida de base64.

De hecho, si vemos el archivo decoded:

Cesars-Mac-Pro: cesar$ cat decoded
?Cesars-Mac-Pro: cesar$

¿Ven el signo ? que se agrega al inicio de la segunda línea? Ese es el contenido del archivo decoded. Bueno, de hecho ese es el único caracter imprimible del archivo decoded, en realidad hay otros 2 bytes que no se traducen a nada en ASCII, y por lo tanto no son imprimibles. Para ver el contenido en hexadecimal como nos interesa está hexdump en la terminal:

xxd decoded
0000000: 0000 0040 …@

Como vemos, el valor son 4 bytes: 0000 0040. Ese 0040 es el que debemos cambiar. ¿Pero por cual valor? Un poco de zen cracking me dice que por 0000 0080 ya que 8 es el doble de 4, y 2048 es el doble de 1024. Pero necesitamos mayor evidencia antes de hacer un cambio de este tipo, y gracias a la comunidad hackintosh todo se aclara en http://forum.netkas.org/index.php?topic=222.0

32 – 0×02000000
64 – 0×04000000
128 – 0×08000000
256 – 0×10000000
320 – 0×14000000
512 – 0×20000000
640 – 0×28000000
768 – 0×30000000
1024 – 0×40000000

Estos son los posibles valores para el tamaño de la memoria, pero solo llega hasta 1024. Siguiendo la lógica:

512 – 0×200
1024 – 0×400
2048 – 0×800

Así que ya tenemos confirmación. Ahora tenemos que editar el archivo decoded pero en hexadecimal. Yo uso un editor llamado Hex Fiend pero pueden usar cualquier editor hexadecimal (como 0xED) y cambien ese 0040 por 0080, de tal manera que cuando verifiquen en la terminal de nuevo, salga algo como lo siguiente:

xxd decoded
0000000: 0000 0080 ….

Ahora lo que resta es codificarlo de vuelta a base64 y ver que tenemos de regreso. En la terminal:

base64 -i decoded -o result

Lo que nos da finalmente el resultado que buscamos:

cat decoded
AAAAgA==

Esa cadena, AAAAgA== es la que tenemos que poner en vez de AAAAQA== ¿Pero en donde? en Natit.kext, sin embargo tenemos que hacer el cambio en el kext que aún no se encuentra en /System/Library/Extensions/ o sea, el que descargaron originalmente. Supongamos que descargamos el paquete de la guía de OSx86 a nuestro directorio home, entonces tendremos algo como:

~/[NEW]GT430[1GB].by.KemalALKIN/[NEW]Natit/Natit.kext

Y ese es el kext que debemos editar. Una vez editado, ejecutamos ka Kext Utility (también incluída en el paquete), reiniciamos y eso es todo.