Desde octubre de 2009 cuento con una XBOX 360 que mi amigo MagmaD me vendió amablemente. Se trata de una de las XBOX Premium de primera generación, que después de mostrar el famoso "Aro Rojo de la Muerte" fue resucitada por el siempre hábil y confiable departamento de Servicio Técnico de Microsoft. Antes de vendérmela, mi amigo la mandó flashear del lector con el penúltimo firmware iXtreme de la fecha (el 1.4) y actualizó el dashboard a la versión que cubría el xploit necesario para poder grabar por JTAG la memoria NAND del XBOX 360. Yo no me conecto al XBOX Live, en parte por falta de tiempo, falta de dinero y principalmente por falta de internet alámbrico.
En invierno de 2009 salió a la venta el juego de Bayonetta, y por desgracia mi XBOX 360 no podía leer el disco del juego. Resulta que los juegos de XBOX 360 van cambiando sus medidas de seguridad al paso del tiempo, para complicarle la existencia a los usuarios que hacen uso de respaldos de discos para jugar. A esos cambios en la arquitectura del disco se les llama WAVES, y en mi caso, el firmware que tenía mi lector (iXtreme 1.4) sólo podía leer discos de WAVE 1 y WAVE 2. Para solventar el problema, existe una herramienta llamada PPF-o-matic, que permite arreglar las particiones de las imágenes de disco para que coincidan con el WAVE 2 (iXtreme 1.4) o WAVE 3 (iXtreme 1.5).
Sin embargo, recientemente Microsoft lanzó un par de medidas de seguridad que le están dando varios dolores de cabeza a mucha gente. Dichas protecciones son el AP 2.5 y el formato de disco XGD 3. Ambas medidas de seguridad se encuentran en los principales juegos de la actualidad, como son Gears of War 3, Halo Reach y Call of Duty - Modern Warfare 3. Por suerte, son juegos que no me interesan en lo más mínimo, así que mi XBOX 360 se mantuvo inmutable ante esa circunstancia.
Sin embargo, recientemente apareció un juego que si llamó mi atención, se trata de The King of Fighters 13. Este título no cuenta con ninguna de las protecciones mencionadas en el párrafo anterior, sin embargo el disco es de un WAVE muy avanzado (WAVE 13). Para correr un juego de WAVE 12 o WAVE 13 es necesario actualizar la interfaz de usuario del XBOX 360 a la versión más reciente. Pues dispuesto a probar el título en cuestión, traté de aplicar la actualización del juego, pero saltó un error y la XBOX 360 se trabó. Después de desconectar de la corriente eléctrica el XBOX 360 y volverlo a encender, noto aliviado que todo estaba normal. Traté de volver de aplicar la actualización, esta vez por medio de USB y el error volvió a saltar.
Después de documentarme un poco en internet, descubrí que el causante del error que impedía a mi XBOX 360 actualizar era el firmware iXtreme 1.4 que tenía mi lector. Las actualizaciones más recientes graban en el lector de consola un nuevo firmware que soporta el formato de disco XGD 3, pero si la actualización detecta que el firmware del lector está alterado se detiene. La solución al problema es relativamente simple, hay que devolver al lector su firmware de fábrica antes de aplicar la actualización.
Solución simple, pero no sencilla, mucho menos cuando no se dispone de una computadora de escritorio. Mi amigo MaxClowReed me ofreció su tiempo y su computadora de escritorio para realizar el flasheo del lector, sin embargo debido compromisos laborales y circunstancias personales no se pudo concretar el acuerdo, además es un tanto arriesgado desplazar una XBOX 360 o una computadora de escritorio por las siempre seguras calles y avenidas del Estado de México.
Después de documentarme un poco sobre el procedimiento de flasheo del lector, decidí hacer un experimento. Lo primero es conocer al enemigo, en este caso, es preciso saber cuál es el modelo del lector que tiene la XBOX 360, ya que existen de muchos modelos y fabricantes. Mi XBOX 360 cuenta con un lector Samsung (conocido en los foros como Sammy) y hasta donde pude averiguar, es uno de los más fáciles de flashear. Lo segundo es recolectar los materiales necesarios para el flasheo. En mi caso, solo dispongo de una computadora tipo notebook, modelo Compaq Presario V3000, célebre porque tiene su propia versión del "Aro Rojo de la Muerte" conocida como "Focos Azules de la Muerte". Bueno, mi notebook todavía enciende si la tratas con cariño y se encuentra de buen humor, además de que es compatible con la utilidad de flasheo de línea de comandos llamada DOSFLASH, necesaria para llevar a cabo el proceso de flasheo.
Otra utilidad que es necesaria es el FIRMTOOL, que permite extraer la llave del lector y colocarla en otro firmware. Cada XBOX 360 se encuentra pareado con un lector de DVD, si la unidad lectora se cambia por otra cuya llave no coincida, el sistema no funciona. Al modificar el firmware del lector es muy importante grabar la llave (única e irrepetible) de nuestro lector en el firmware, para que no haya inconvenientes.
En cuanto a hardware, hay dos problemas. El primero es que el uníco puerto SATA con que cuenta la notebook es especial para discos duros de laptop, por lo que su terminal tiene una forma peculiar que encaja en un caddy. El caddy contiene un disco duro convencional de 2.5 pulgadas y un adaptador para el caddy. La forma que encontré para solventar este problema fue fabricar una extensión SATA, cortando un cable SATA convencional y soldándole un conector macho a los alambres. Dicha extensión se conecta al adaptador del caddy. El segundo problema es la alimentación del lector, ya que la notebook no cuenta con terminales de alimentación como los que tiene el XBOX 360. Este problema se solventó cortando un cable USB y soldando en los extremos del cable negro y rojo un pedazo de alambre calibre 22. Dichos cables se insertan en el cable de alimentación del lector del XBOX 360, el rojo en el pin 8 y el negro en el pin 7. Con esos dos pines basta para alimentar la tarjeta lógica del lector y poder manipular la memoria serial que contiene el firmware.
Ahora, sólo es cuestión de conectar ambos cables a la notebook. Para mi comodidad, yo coloqué la notebook apoyandose en sus bisagras, formando una "v" con la pantalla y el panel del CPU. De esta forma tuve acceso al cable SATA para verificar su conexión, ya que estaba un poco inestable. Para realizar el flasheo se necesita formatear una memoria USB y hacerla arrancable. En Windows se puede utilizar la utilidad de HP para hacer discos arrancables. También se necesitan los archivos de alguna versión de DOS, que pueden proceder del disquete de arranque de un Windows de la serie 9x, del DOS 6.2 o de FreeDOS. Una vez que se formatea la USB, se hace arrancable y se le instalan los archivos de sistema COMMAND.COM, IO.SYS y MSDOS.SYS es necesario copiar los ejecutables de DOSFLASH y FIRMTOOL.
Hasta este punto ya se puede proceder con el flasheo del lector, se conectan la memoria USB, el cable USB que usaremos como alimentación y el cable SATA del lector a la computadora. Se enciende la computadora y se configura el BIOS para que arranque desde la unidad USB. Una vez que haya arrancado la computadora y muestre el cursor del COMMAND.COM, hay que teclear DOSFLASH.
DOSFLASH nos mostrará una lista de los dispositivos ATAPI conectados a la computadora, en el puerto SATA Primario Maestro debe aparecer el lector de XBOX 360. Posteriormente nos preguntará si deseamos mandar unos códigos hasta que el lector responda a lo que contestamos Y. Posteriormente quedará el status del lector en 0x50, le quitamos la alimentación al lector (desconectando el cable USB) y el status cambiará a 0xD0, posteriormente volvemos a conectar el cable USB y el status cambiará a 0x70 y el programa seguirá con su proceso hasta que pregunta cuál dispositivo vamos a flashear, contestamos el número que está a la izquierda del lector de XBOX 360 (en mi caso fue 4) y qué acción queremos tomar en el lector. En este caso respondemos r (Read) ya que primero vamos a extraer el firmware actual del lector (para recuperar la llave del lector). Nos solicitará un nombre de archivo para guardar el firmware, a lo cual podemos emplear cualquier nombre que queramos pero se recomienda ORIG.BIN. Se generará en nuestra USB un archivo de 256 kB que contiene el firmware actual de nuestro lector y su preciada llave. Es importante respaldar este archivo. En mi caso, después de leer el firmware la notebook se trabó, por lo que la apagué y no hubo inconvenientes.
Tenemos que grabar en nuestra memoria USB el firmware que queremos poner a nuestro lector, en mi caso el firmware stock del lector Samsung MS28, al cual le puse simplemente el nombre de archivo STOCK.BIN. Tecleamos en la línea de comandos FIRMTOOL ORIG.BIN STOCK.BIN para que el programa inyecte la llave de nuestro firmware actual (ORIG.BIN) al firmware que vamos a ponerle a nuestro lector (STOCK.BIN).
Finalmente volvemos a encender la notebook, tecleamos DOSFLASH y repetimos el proceso de lectura del firmware, hasta el punto donde pregunta la acción que deseamos tomar en el lector, en esta ocasión responderemos w (Write) y enseguida tecleamos el nombre del firmware que deseamos grabar en el lector (en mi caso STOCK.BIN). Al terminar de grabar la memoria del lector, mi notebook se volvió a trabar, por lo que la apaque y de nuevo no hubo inconvenientes.
En este punto volvemos a conectar el lector en el XBOX 360 y reensamblamos la consola. Al actualizar por USB la consola ya no apareció ningún error. En un punto de la actualización la consola me pidió que conectara el disco duro u otro medio de almacenamiento debido a que la actualización necesitaba de 190 MB adicionales de espacio. Supongo que en XBOX 360 con memoria interna no debe aparecer dicho aviso.
Finalmente se concretó la actualización y mi XBOX 360 perdió la capacidad de leer respaldos, pero ganó la posibilidad de leer los discos originales más nuevos. Es posible en este punto volver a flashear el lector de la consola con un firmware iXtreme LT+, repitiendo todo el procedimiento y sólo cambiando el firmware objetivo. Sin embargo hice la prueba con el LT+ 2.01 y la consola no pudo leer ningún respaldo con el WAVE parcheado, así que opté por revertir este último proceso.
Por último, un saludo y feliz 2012.
sábado, 31 de diciembre de 2011
lunes, 28 de noviembre de 2011
Tres son multitud
El fin se acerca...
Así es, se acerca el fin del año y con él, el fin de semestre. Los proyectos de la escuela han estado muy interesantes, sin embargo han dejado muy poco tiempo para refinar los proyectos personales. En una entrada anterior mencioné que había puesto en el banco de pruebas un control de Sega Saturn y un stick de Sega Genesis. Pues bien, mi idea era construir un mini-retro-adapter-usb que soportara tanto controles de SNES, como de Saturn y de Genesis. El objetivo era mantener cada dispositivo independiente, de tal suerte que se pudiesen emplear los tres tipos de controles de manera simultánea (aunque claro, quien utilizara el control de Saturn tendría una notable ventaja).
Sin embargo, al generar reportes con dos o más dispositivos, Ubuntu (y al parecer la gran mayoría de las distribuciones de Linux) tiene problemas al reconocer los controles como tales, ya que en su lugar los considera como una especie de dispositivo apuntador. Al mover las direcciones de alguno de los controles, el cursor del ratón reaccionaba a los movimientos, además de que las aplicaciones no reconocían a los controles como tales.
Después de probar distintas combinaciones de parámetros en los reportes, logré que dos dispositivos fueran reconocidos correctamente, sin embargo, al agregar el tercer dispositivo los problemas volvían a hacerse presentes.
Por ello, he decidido liberar un adaptador que permite conectar un control de Saturn y uno de Genesis de forma simultánea. Utilizando las rutinas de lectura de cada dispositivo es posible hacer las combinaciones de controles que sean necesarias. Por mi cuenta, la combinación ganadora es el adaptador Saturn-Genesis y el adaptador de dos controles de SNES. No me parece una buena idea realizar un adaptador USB para controles para Playstation debido a tres cosas. La primera es que el ATTINY2313 no tiene interfaz SPI, lo que implicaría realizar el protocolo por bitbang. La segunda es que los controles de Playstation no me agradan. La tercera y más importante es que el adaptador de controles de Playstation a USB que venden en las tiendas Steren es más barato que los materiales para hacer un adaptador casero.
El firmware, con su código fuente y su esquema de conexiones está en la siguiente liga:
Adaptador de controles de Saturn y Genesis a USB
Así es, se acerca el fin del año y con él, el fin de semestre. Los proyectos de la escuela han estado muy interesantes, sin embargo han dejado muy poco tiempo para refinar los proyectos personales. En una entrada anterior mencioné que había puesto en el banco de pruebas un control de Sega Saturn y un stick de Sega Genesis. Pues bien, mi idea era construir un mini-retro-adapter-usb que soportara tanto controles de SNES, como de Saturn y de Genesis. El objetivo era mantener cada dispositivo independiente, de tal suerte que se pudiesen emplear los tres tipos de controles de manera simultánea (aunque claro, quien utilizara el control de Saturn tendría una notable ventaja).
Sin embargo, al generar reportes con dos o más dispositivos, Ubuntu (y al parecer la gran mayoría de las distribuciones de Linux) tiene problemas al reconocer los controles como tales, ya que en su lugar los considera como una especie de dispositivo apuntador. Al mover las direcciones de alguno de los controles, el cursor del ratón reaccionaba a los movimientos, además de que las aplicaciones no reconocían a los controles como tales.
Después de probar distintas combinaciones de parámetros en los reportes, logré que dos dispositivos fueran reconocidos correctamente, sin embargo, al agregar el tercer dispositivo los problemas volvían a hacerse presentes.
Por ello, he decidido liberar un adaptador que permite conectar un control de Saturn y uno de Genesis de forma simultánea. Utilizando las rutinas de lectura de cada dispositivo es posible hacer las combinaciones de controles que sean necesarias. Por mi cuenta, la combinación ganadora es el adaptador Saturn-Genesis y el adaptador de dos controles de SNES. No me parece una buena idea realizar un adaptador USB para controles para Playstation debido a tres cosas. La primera es que el ATTINY2313 no tiene interfaz SPI, lo que implicaría realizar el protocolo por bitbang. La segunda es que los controles de Playstation no me agradan. La tercera y más importante es que el adaptador de controles de Playstation a USB que venden en las tiendas Steren es más barato que los materiales para hacer un adaptador casero.
El firmware, con su código fuente y su esquema de conexiones está en la siguiente liga:
Adaptador de controles de Saturn y Genesis a USB
sábado, 22 de octubre de 2011
No soy yo... ¡Eres tú!
En algunos post anteriores, debrayé un poco sobre el protocolo de comunicación del control de Playstation y algunas de sus características, así como la evidente lentitud de dicho protocolo.
En estos días estuve experimentando un poco con otro tipo de controles, que usan un protocolo de comunicación muy simple (inclusive más simple que el utilizado por el control de SNES) en el banco de pruebas, haciendo adaptadores USB de dichos controles. En esta ocasión las víctimas de los experimentos fueron un stick de seis botones para Sega Genesis y un control de Sega Saturn.
Ambos controles basan su funcionamiento en un multiplexor, en el cual el estado de la terminal de selección determina cuáles botones serán puestos en las líneas de datos. El control de Genesis tiene una sola línea de selección y seis líneas de datos, por lo que la lectura de los estados de todos los botones es muy rápida. El control de Saturn funciona de forma similar, sólo que en éste caso se tienen dos líneas de selección y cuatro líneas de datos.
En la computadora, ambos controles funcionaron bien. Sin embargo, al tratar de probar los controles en su plataforma destino ahí fue donde todo valió... ¡Un momento! ¡Eso ya lo he escrito antes X_x!
Aquí ya todo comenzó a verse muy sospechoso. Las desconexiones que sufría la interfaz con el control de Playstation las atribuí a las demoras en la entrega de datos del control, sin embargo, cuando el problema persistió en otros controles que son mucho más rápidos fue cuando comprendí que el problema residía en otra parte. Hice unas pruebas de lectura de puerto... y ahí salió el culpable.
La interfaz para el MapleBus hecha con un ATTINY25 funcionó muy bien, pues aunque en ocasiones había errores en la recepción de bits, unas rutinas de reconstrucción de datos muy básicas permitían leer de forma consistente el bus. Para conectar al Maplebus los controles de Playstation, de Genesis y de Saturn es necesario utilizar un microcontrolador con más pines que los ocho que tiene el ATTINY25. Mi elección fue el ATTINY2313.
Para mantener la sincronía con el MapleBus, el ATTINY25 funciona a una frecuencia de 16MHz. La señal de reloj es generada por el oscilador interno (que funciona a 1MHz) y un PLL (Phase-Locked Loop) que escala esa frecuencia hasta 64MHz. El microcontrolador divide internamente la frecuencia del PLL entre cuatro, lo que da como resultado la señal de reloj de 16MHz. Esta señal de reloj es muy inestable y varía mucho su valor.
El ATTINY2313 no cuenta con un PLL, por lo que la señal de reloj es provista por un cristal de cuarzo de 16MHz. El cristal genera una señal de reloj muy estable.
Al portar el programa del ATTINY25 al ATTINY2313, uno esperaría que ambos circuitos funcionaran de forma similar, o inclusive, que el ATTINY2313 fuese capaz de mantener la sincronía con el bus de una forma más efectiva que el ATTINY25, ya que su señal de reloj es mucho más estable. Sin embargo, el resultado fue completamente opuesto, el ATTINY2313 entregaba demasiados errores de lectura.
Con unas modificaciones en el firmware, pude conectar de forma satisfactoria el control de Saturn al MapleBus, aunque el adaptador provoca tres errores relativamente graves. El primero es que al ser conectado, el adaptador no siempre funciona, así que es necesario intentar la conexión un par de veces. El segundo problema es que al iniciar algún juego, la interfaz se desconecta. La tercera es que los botones C y Z no son reconocidos dentro de las opciones de los juegos, aunque misteriosamente ambos botones funcionan correctamente al ser pulsados. Una vez que la interfaz es reconocida por el juego, no sufre desconexiones.
Resta hacer pruebas con la interfaz modificada y el control de Playstation, sin embargo he llegado a la conclusión que se necesita de otro tipo de circuitos para realizar una interfaz que responda de forma más confiable y que permita añadir soporte para periféricos. El microcontrolador es una herramienta muy útil, aunque en la interfaz con el MapleBus es necesario utilizar muchos trucos para establecer la comunicación. Debido a la arquitectura del MapleBus, al parecer es más conveniente realizar la interfaz con un CPLD (Complex Programmable Logic Device), que sea capaz de responder a los cambios de nivel en la señal y mantenga la sincronía en todo momento con la interfaz.
En estos días estuve experimentando un poco con otro tipo de controles, que usan un protocolo de comunicación muy simple (inclusive más simple que el utilizado por el control de SNES) en el banco de pruebas, haciendo adaptadores USB de dichos controles. En esta ocasión las víctimas de los experimentos fueron un stick de seis botones para Sega Genesis y un control de Sega Saturn.
Ambos controles basan su funcionamiento en un multiplexor, en el cual el estado de la terminal de selección determina cuáles botones serán puestos en las líneas de datos. El control de Genesis tiene una sola línea de selección y seis líneas de datos, por lo que la lectura de los estados de todos los botones es muy rápida. El control de Saturn funciona de forma similar, sólo que en éste caso se tienen dos líneas de selección y cuatro líneas de datos.
En la computadora, ambos controles funcionaron bien. Sin embargo, al tratar de probar los controles en su plataforma destino ahí fue donde todo valió... ¡Un momento! ¡Eso ya lo he escrito antes X_x!
Aquí ya todo comenzó a verse muy sospechoso. Las desconexiones que sufría la interfaz con el control de Playstation las atribuí a las demoras en la entrega de datos del control, sin embargo, cuando el problema persistió en otros controles que son mucho más rápidos fue cuando comprendí que el problema residía en otra parte. Hice unas pruebas de lectura de puerto... y ahí salió el culpable.
La interfaz para el MapleBus hecha con un ATTINY25 funcionó muy bien, pues aunque en ocasiones había errores en la recepción de bits, unas rutinas de reconstrucción de datos muy básicas permitían leer de forma consistente el bus. Para conectar al Maplebus los controles de Playstation, de Genesis y de Saturn es necesario utilizar un microcontrolador con más pines que los ocho que tiene el ATTINY25. Mi elección fue el ATTINY2313.
Para mantener la sincronía con el MapleBus, el ATTINY25 funciona a una frecuencia de 16MHz. La señal de reloj es generada por el oscilador interno (que funciona a 1MHz) y un PLL (Phase-Locked Loop) que escala esa frecuencia hasta 64MHz. El microcontrolador divide internamente la frecuencia del PLL entre cuatro, lo que da como resultado la señal de reloj de 16MHz. Esta señal de reloj es muy inestable y varía mucho su valor.
El ATTINY2313 no cuenta con un PLL, por lo que la señal de reloj es provista por un cristal de cuarzo de 16MHz. El cristal genera una señal de reloj muy estable.
Al portar el programa del ATTINY25 al ATTINY2313, uno esperaría que ambos circuitos funcionaran de forma similar, o inclusive, que el ATTINY2313 fuese capaz de mantener la sincronía con el bus de una forma más efectiva que el ATTINY25, ya que su señal de reloj es mucho más estable. Sin embargo, el resultado fue completamente opuesto, el ATTINY2313 entregaba demasiados errores de lectura.
Con unas modificaciones en el firmware, pude conectar de forma satisfactoria el control de Saturn al MapleBus, aunque el adaptador provoca tres errores relativamente graves. El primero es que al ser conectado, el adaptador no siempre funciona, así que es necesario intentar la conexión un par de veces. El segundo problema es que al iniciar algún juego, la interfaz se desconecta. La tercera es que los botones C y Z no son reconocidos dentro de las opciones de los juegos, aunque misteriosamente ambos botones funcionan correctamente al ser pulsados. Una vez que la interfaz es reconocida por el juego, no sufre desconexiones.
Resta hacer pruebas con la interfaz modificada y el control de Playstation, sin embargo he llegado a la conclusión que se necesita de otro tipo de circuitos para realizar una interfaz que responda de forma más confiable y que permita añadir soporte para periféricos. El microcontrolador es una herramienta muy útil, aunque en la interfaz con el MapleBus es necesario utilizar muchos trucos para establecer la comunicación. Debido a la arquitectura del MapleBus, al parecer es más conveniente realizar la interfaz con un CPLD (Complex Programmable Logic Device), que sea capaz de responder a los cambios de nivel en la señal y mantenga la sincronía en todo momento con la interfaz.
martes, 4 de octubre de 2011
La vida con Linux.
En la asignatura de Diseño Digital, estamos experimentando con unos dispositivos llamados PLD (Programmable Logic Device). En particular, estamos trabajando con la GAL22V10, que es un dispositivo un tanto obsoleto, pero que sirve excepcionalmente bien para implementar diseños y prototipos combinacionales y secuenciales sencillos. Un PLD es un circuito integrado que en su interior contiene arreglos de compuertas, flipflops y multiplexores que pueden ser "programados" para que se comporten de una forma específica. Prácticamente, permite fabricar nuestros propios circuitos integrados.
Uno de los paquetes de software de síntesis y simulación que se emplea en la asignatura es el Quartus II de Altera. Mi profesor tiene en su página web algunos recursos enfocados a la clase, pero como la URL de su página es difícil de memorizar, para acceder a la página nos recomendó que buscásemos su nombre en Google y el primer resultado apuntaría a la página.
Después de obtener los recursos que me interesaban de la página del profesor, decidí buscarme a mí mismo en Google, para ver "mis pasos". Entre lo que encontré fue un reply que hice en el foro de ubuntu.es en respuesta a un topic en el cual un usuario (quizás al día de hoy, exusuario) de Ubuntu despotricaba contra el sistema operativo, haciendo evidentes una serie de defectos y errores en su computadora derivados del uso de Ubuntu.
Mi reply no fue ni popular ni impopular, simplemente fue ignorada y se perdió entre todas las respuestas que llenaron el topic. Sin embargo, me gustaría rescatarla y ponerla en el blog.
Cuando empecé a utilizar Linux de forma cotidiana (como regla autoimpuesta), me entró un poco la fiebre "evangelizadora" y traté de mostrarles lo bueno que era el sistema a mis compañeros de la escuela más cercanos. Sin embargo, al primer "detalle", todos decidieron abandonar el barco de Ubuntu. Eso no me defraudó ni me frustró, me causo pena (en este caso, pena ajena).
A partir de ese momento decidí no hacer difusión por cuenta propia de Linux, no por egoísta ni por frustración. Comprendí que cuando la gente quiere algo, lo busca y lucha por ello hasta que lo consigue. Pero cuando la gente obtiene cosas que no busca, muchas veces las descarta o desprecia. Cuando eso ocurre, se desperdician oportunidades... y cuando se desperdician oportunidades se cosecha el fracaso.
Actitud positiva y emprendedora abre puertas. Actitud pesimista y retrógrada... quizás no cierre puertas, pero evita que se abran.
Uno de los paquetes de software de síntesis y simulación que se emplea en la asignatura es el Quartus II de Altera. Mi profesor tiene en su página web algunos recursos enfocados a la clase, pero como la URL de su página es difícil de memorizar, para acceder a la página nos recomendó que buscásemos su nombre en Google y el primer resultado apuntaría a la página.
Después de obtener los recursos que me interesaban de la página del profesor, decidí buscarme a mí mismo en Google, para ver "mis pasos". Entre lo que encontré fue un reply que hice en el foro de ubuntu.es en respuesta a un topic en el cual un usuario (quizás al día de hoy, exusuario) de Ubuntu despotricaba contra el sistema operativo, haciendo evidentes una serie de defectos y errores en su computadora derivados del uso de Ubuntu.
Mi reply no fue ni popular ni impopular, simplemente fue ignorada y se perdió entre todas las respuestas que llenaron el topic. Sin embargo, me gustaría rescatarla y ponerla en el blog.
Es una cuestión de actitud...
Realmente me sentí identificado con el post.
Recuedo hace varios ayeres, cuando traté de iniciarme en el mundo Linux con un LiveCD que gentilmente un compañero de la escuela me regaló. Traté de probar el SO que contenía (justamente Ubuntu), pues en la cubierta (era de los CDs que te llegan por correo) decía que podía probarlo sin compromiso... lo puse, vi la splash screen de Ubuntu y... ¡no paso nada!!!
En mi PC todo estaba bien configurado (BIOS, hardware, etc). Resulto que mi tarjeta de video ATI y el video integrado Intel (que no hay forma de desactivar ni por BIOS, ni jumper, ni soldadura...) causaban un conflicto y Ubuntu (ni cualquier Linux o Free BSD) no podía mostrar el entorno gráfico.
Paso el tiempo, cambie de PC y volví a darme la oportunidad de probar Linux, ahora en forma de Kubuntu. En esa ocasión no tuve problemas con el entorno gráfico, la instalación fue satisfactoria. Trabajé dos felices días con él, hasta que el tercer día configuré el Kopete para charlar con mis amigos, apagué la PC y al volverla encender... dejó de mostrar el entorno gráfico.
Hasta acá, creo que lo más sensato era abandonar la idea de usar Linux y hacerle caso a la calcomanía que orgullosamente ostenta mi PC "Designed for Windows XP" n_n. Pero, la verdad... creo que mi estado natural es la locura, así que volví a hacer la prueba con Linux... ahora con Mint. Ahora ya llevo bastante tiempo en Linux Mint, todo funciona como me conviene (claro, documentación de por medio) y si bien he tenido algunos problemas (como todo el mundo), el resolverlos ha sido gratificante (he aprendido mucho) y enriquecedor (gracias al apoyo de usuarios de los foros como éste).
La computadora debe trabajar para el usuario, no al revés, estoy de acuerdo con este planteamiento. Sin embargo, usar la computadora también requiere de compromiso, pues ella responderá de la forma en que el usuario la ha programado. La única crítica, es que uno no puede afirmar que tenga conocimientos de informática superiores a los de la mayoría de la gente... eso es pura soberbia.
Linux es perfectible, avanza y crece gracias a los usuarios. Se debe tener una actitud positiva y emprendedora, sobre todo cuando aun hay tanto por hacer.
Cuando empecé a utilizar Linux de forma cotidiana (como regla autoimpuesta), me entró un poco la fiebre "evangelizadora" y traté de mostrarles lo bueno que era el sistema a mis compañeros de la escuela más cercanos. Sin embargo, al primer "detalle", todos decidieron abandonar el barco de Ubuntu. Eso no me defraudó ni me frustró, me causo pena (en este caso, pena ajena).
A partir de ese momento decidí no hacer difusión por cuenta propia de Linux, no por egoísta ni por frustración. Comprendí que cuando la gente quiere algo, lo busca y lucha por ello hasta que lo consigue. Pero cuando la gente obtiene cosas que no busca, muchas veces las descarta o desprecia. Cuando eso ocurre, se desperdician oportunidades... y cuando se desperdician oportunidades se cosecha el fracaso.
Actitud positiva y emprendedora abre puertas. Actitud pesimista y retrógrada... quizás no cierre puertas, pero evita que se abran.
jueves, 15 de septiembre de 2011
Simple siempre es mejor... ¿o no?
Bajo la idea del post anterior y como diría Sun Tzu: "Conoce a tu enemigo..."
Decidí ver qué secretos escondía el control Nubytech de Street Fighter que había adquirido y la mejor forma de descubrirlos era echándole un vistazo al interior del control.
En esta foto podemos apreciar el control, que tiene el tema de Chun Li. Aunque la combinación de colores no me convence del todo, no es desagradable. Existen cuatro modelos de control para PS2: Ryu, Ken, Chun Li y Akuma. Sin embargo, el de Akuma es sumamente difícil de conseguir, lo cual atribuyo a que Akuma es un personaje muy popular y a que la combinación de colores del control (negro y rojo) es muy atractiva. No tengo queja del personaje del control que prácticamente "me toco" ya que Chun Li es uno mis personajes preferidos, con ella fuí capaz de acabar el Street Fighter II -The World Warrior- en nivel 7 con todos los rounds Perfect... y darme cuenta que el final no cambiaba X_x.
En esta foto se ha retirado la tapa trasera del control y se puede apreciar una sola placa de circuito. Vemos los capacitores que inhiben el ruido inducido y estabilizan la alimentación. El cable se ve bastante frágil y está unido a la placa de forma mecánica por una insignificante cinta diurex.
Hasta este punto, es posible ver que la construcción del control no se compara con la de los DualShock o incluso con la de controles de SNES originales.
Y aquí ya de plano se le pierde el respeto por completo al control. Es posible apreciar la clásica gota negra que caracteriza a la mayoría de la circuitería china de mala calidad (con todo respeto y sin afán de ofender).
El control, a nivel lógico se comporta como un control digital de Playstation. Inclusive puede usarse para bootear el Valkyrie Profile 2 desde HDLoader y evitar que se trabe en las batallas.
Respecto a la funcionalidad y comodidad del control no tengo queja alguna, es más, afirmo que es el control digital más cómodo que me ha tocado probar para juegos de peleas, aún por encima que el control de SNES. Sin embargo, al ver su pobre construcción no puedo dejar de sentir una leve decepción.
Yo pagué $160.00 pesos mexicanos (aproximadamente $12.30 USD) por este control, precio que me parece "apropiado" considerando que se trataba de un artículo nuevo. Sin embargo he visto que el control de Akuma se anda cotizando hasta en $900.00 pesos mexicanos (aproximadamente $70.00 USD), lo cual es un verdadero robo. El paquete completo de los cuatro controles también se cotiza caro y si bien son controles que cumplen muy bien con su objetivo en cuestión de funcionalidad, su valor de colección es escaso y su calidad de construcción también lo es, así que solo me queda recomendarles que no se dejen apantallar.
Decidí ver qué secretos escondía el control Nubytech de Street Fighter que había adquirido y la mejor forma de descubrirlos era echándole un vistazo al interior del control.
En esta foto podemos apreciar el control, que tiene el tema de Chun Li. Aunque la combinación de colores no me convence del todo, no es desagradable. Existen cuatro modelos de control para PS2: Ryu, Ken, Chun Li y Akuma. Sin embargo, el de Akuma es sumamente difícil de conseguir, lo cual atribuyo a que Akuma es un personaje muy popular y a que la combinación de colores del control (negro y rojo) es muy atractiva. No tengo queja del personaje del control que prácticamente "me toco" ya que Chun Li es uno mis personajes preferidos, con ella fuí capaz de acabar el Street Fighter II -The World Warrior- en nivel 7 con todos los rounds Perfect... y darme cuenta que el final no cambiaba X_x.
En esta foto se ha retirado la tapa trasera del control y se puede apreciar una sola placa de circuito. Vemos los capacitores que inhiben el ruido inducido y estabilizan la alimentación. El cable se ve bastante frágil y está unido a la placa de forma mecánica por una insignificante cinta diurex.
Hasta este punto, es posible ver que la construcción del control no se compara con la de los DualShock o incluso con la de controles de SNES originales.
Y aquí ya de plano se le pierde el respeto por completo al control. Es posible apreciar la clásica gota negra que caracteriza a la mayoría de la circuitería china de mala calidad (con todo respeto y sin afán de ofender).
El control, a nivel lógico se comporta como un control digital de Playstation. Inclusive puede usarse para bootear el Valkyrie Profile 2 desde HDLoader y evitar que se trabe en las batallas.
Respecto a la funcionalidad y comodidad del control no tengo queja alguna, es más, afirmo que es el control digital más cómodo que me ha tocado probar para juegos de peleas, aún por encima que el control de SNES. Sin embargo, al ver su pobre construcción no puedo dejar de sentir una leve decepción.
Yo pagué $160.00 pesos mexicanos (aproximadamente $12.30 USD) por este control, precio que me parece "apropiado" considerando que se trataba de un artículo nuevo. Sin embargo he visto que el control de Akuma se anda cotizando hasta en $900.00 pesos mexicanos (aproximadamente $70.00 USD), lo cual es un verdadero robo. El paquete completo de los cuatro controles también se cotiza caro y si bien son controles que cumplen muy bien con su objetivo en cuestión de funcionalidad, su valor de colección es escaso y su calidad de construcción también lo es, así que solo me queda recomendarles que no se dejen apantallar.
domingo, 11 de septiembre de 2011
Simple siempre es mejor...
Últimamente he estado experimentando un poco con controles de Playstation. A mi gusto, los controles originales de Playstation, tanto digitales como analógicos son bastante incómodos y poco acertados. Sin embargo, son controles que pueden encontrarse en prácticamente todos lados, desde tiendas de autoservicios hasta tianguis y mercados sobre ruedas, por lo que son una buena opción para sustituir los controles de alguna otra consola que no cuenten con tanta disponibilidad o que tengan precios elevados debido a su rareza.
Inclusive en muchos lugares, incluyendo MercadoLibre, los controles genéricos de SNES suelen cotizarse al mismo precio que los controles genéricos de Playstation, cosa por demás extraña, considerando que la complejidad en circuito y fabricación de un control de Playstation esta muy por encima de la de un control de SNES.
A pesar de que el control de Playstation no me convence, recientemente adquirí un control Nubytech conmemorativo del decimoquinto aniversario de Street Fighter II. A pesar de esos controles ya llevan mucho tiempo en el mercado, no me habían llamado la atención debido a que a simple vista es posible apreciar que carecen de controles analógicos. Es decir, no sirven para todos los juegos. Sin embargo un detalle me hizo verlos con interés, el hecho de que tienen una disposición de botones más que apropiada para juegos de peleas y su forma es muy ergonómica, parecida a la de un control de Sega Saturn modelo 2.
Investigué un poco acerca del protocolo de comunicación de los controles de Playstation, el cual es una variante del SPI (Serial Peripheral Interface) que emplean la mayoría de los microcontroladores. Se trata de un protocolo full duplex que tiene una linea de selección de chip (Attention según el cableado del control de Playstation), una línea MISO (o Data), una línea MOSI (o Command) y una línea de notificación (Acknowledge) que no forma parte de la interfaz SPI. La interfaz funciona a 250[kHz] y a 500[kHz], dependiendo del tipo de control. En teoría, es una interfaz simple de implementar en un microcontrolador y de fácil decodificación, sin embargo me han surgido varios problemas al trabajar con ella.
Mi primer intento fue una interfaz SPI hecha a base de bitbang usando el ATTINY2313 (mi microcontrolador consentido), en la cual por USB sólo funcionó con el control Nubytech antes citado y el Lavaglow wireless. No pudo establecer comunicación con ningún control original. A pesar de todo, eso era suficiente para llevar las pruebas a su plataforma destino... y ahí fue donde todo valió.
Si bien, la decodificación y el mapeo de los botones funcionó perfectamente, la interfaz sufría desconexiones a frecuencia constante de 1[Hz]. Al parecer la interfaz SPI por bitbang es muy lenta y no permite mantener la sincronía con una interfaz más veloz.
De ahí viene el título de este post... es bastante más efectivo en términos de tiempo, complejidad y costo un control digital tipo SNES (con registros de corrimiento en su interior) que un control digital tipo Playstation, que con sólo dos botones extras complica demasiado la decodificación y compromete la velocidad de reacción del sistema.
Inclusive en muchos lugares, incluyendo MercadoLibre, los controles genéricos de SNES suelen cotizarse al mismo precio que los controles genéricos de Playstation, cosa por demás extraña, considerando que la complejidad en circuito y fabricación de un control de Playstation esta muy por encima de la de un control de SNES.
A pesar de que el control de Playstation no me convence, recientemente adquirí un control Nubytech conmemorativo del decimoquinto aniversario de Street Fighter II. A pesar de esos controles ya llevan mucho tiempo en el mercado, no me habían llamado la atención debido a que a simple vista es posible apreciar que carecen de controles analógicos. Es decir, no sirven para todos los juegos. Sin embargo un detalle me hizo verlos con interés, el hecho de que tienen una disposición de botones más que apropiada para juegos de peleas y su forma es muy ergonómica, parecida a la de un control de Sega Saturn modelo 2.
Investigué un poco acerca del protocolo de comunicación de los controles de Playstation, el cual es una variante del SPI (Serial Peripheral Interface) que emplean la mayoría de los microcontroladores. Se trata de un protocolo full duplex que tiene una linea de selección de chip (Attention según el cableado del control de Playstation), una línea MISO (o Data), una línea MOSI (o Command) y una línea de notificación (Acknowledge) que no forma parte de la interfaz SPI. La interfaz funciona a 250[kHz] y a 500[kHz], dependiendo del tipo de control. En teoría, es una interfaz simple de implementar en un microcontrolador y de fácil decodificación, sin embargo me han surgido varios problemas al trabajar con ella.
Mi primer intento fue una interfaz SPI hecha a base de bitbang usando el ATTINY2313 (mi microcontrolador consentido), en la cual por USB sólo funcionó con el control Nubytech antes citado y el Lavaglow wireless. No pudo establecer comunicación con ningún control original. A pesar de todo, eso era suficiente para llevar las pruebas a su plataforma destino... y ahí fue donde todo valió.
Si bien, la decodificación y el mapeo de los botones funcionó perfectamente, la interfaz sufría desconexiones a frecuencia constante de 1[Hz]. Al parecer la interfaz SPI por bitbang es muy lenta y no permite mantener la sincronía con una interfaz más veloz.
De ahí viene el título de este post... es bastante más efectivo en términos de tiempo, complejidad y costo un control digital tipo SNES (con registros de corrimiento en su interior) que un control digital tipo Playstation, que con sólo dos botones extras complica demasiado la decodificación y compromete la velocidad de reacción del sistema.
sábado, 20 de agosto de 2011
Adaptador de control de SNES a MapleBUS (Las vacaciones han terminado).
En efecto, las vacaciones de verano han llegado a su fin, y con ello, el deadline del proyecto de vacaciones (que de hecho empezó desde las vacaciones de Semana Santa) ha sido alcanzado. Pues, con una semana de retraso, por fin realicé las pruebas finales y el proyecto funcionó.
MapleBUS es una interfaz de comunicación bidireccional digital half-duplex (es decir, en un instante dado sólo puede transmitir información en un sólo sentido) que es capaz de transmitir información a una tasa de 2[Mb/s]. A nivel físico, la interfaz cuenta con cinco terminales:
A nivel lógico, para la transferencia de información se emplean las terminales SDCKA y SDCKB. De forma general, cuando una de las terminales cambia su nivel de voltaje desde nivel alto (3.3[V]) a GND (es decir, ocurre un flanco de bajada), la interfaz detecta un ciclo de reloj y recoge como dato el nivel de voltaje que tiene la otra terminal. Por ejemplo, supongamos que tanto SDCKA como SDCKB tienen un nivel de 3.3[V], si SDCKA cambia de 3.3[V] a GND, la interfaz toma como dato el nivel de voltaje en SDCKB, en este caso 3.3[V] o "1 lógico". De esta forma se alternan los roles de las terminales SDCKA y SDCKB, ya que mientras una es "reloj", la otra es "dato". Esto permite que a pesar de que la frecuencia de cada señal es de aproximadamente 1[MHz], la interfaz tenga una frecuencia de 2[MHz].
Es una interfaz relativamente compleja de implementar en un microcontrolador, debido a que la mayoría de los microcontroladores de bajo costo sólo permiten leer niveles de voltaje en sus puertos. Algunos permiten detectar cambios de niveles o flancos (tanto de subida como de bajada), lo cual puede activar una interrupción y da la posibilidad al microcontrolador de actuar en consecuencia a los cambios de nivel. Sin embargo, el manejar interrupciones da lugar a un proceso relativamente complejo y lento que no es adecuado para una interfaz veloz.
Por ejemplo, supongamos un microcontrolador AVR trabajando a una frecuencia de 20[MHz] (el límite nominal para muchos ATTINY y ATMEGA), la detección de un flanco de bajada por alguna de las terminales INT0 o INT1 lleva 3 ciclos de reloj, el salto a la interrupción lleva 3 ciclos más, el recoger el dato del puerto lleva un ciclo, almacenarlo en alguna variable puede llevar uno o dos ciclos dependiendo del destino, volver al flujo del programa desde la interrupción lleva 4 ciclos de reloj. El procedimiento anterior consume 12 ciclos de reloj en el mejor de los casos (ya que en el ejemplo no se discrimina entre flanco de subida o bajada ni tampoco se ordena el bit en algún latch), lo cual es demasiado lento, ya que leer dos bits llevaría 24 ciclos de reloj. Dado que la interfaz transmite 2 bits cada [us] y el microcontrolador trabaja a 20 ciclos por [us], es posible notar el déficit de velocidad.
Es posible utilizar registros de corrimiento SIPO (Serial Input - Parallel Output) y latches para capturar los datos y retenerlos mientras el microcontrolador los procesa o leer los datos a través de la técnica de "polling". El polling consiste en monitorizar en un ciclo el estado de una variable o puerto y actuar acorde a él sin emplear interrupciones. Esta técnica es muy ineficiente, sin embargo es una alternativa viable en términos de velocidad y complejidad de circuito.
Gracias a la información otorgada por Marcus Comstedt y Sodor (A.K.A. leucemidus) fue posible implementar esta interfaz.
El primer (y hasta el momento único prototipo) utiliza sólo un ATTINY25... y nada más n_n. De hecho, pueden agregarse resistencias para proteger los pines conectados a la interfaz (47 o 68 omhs deben estar bien), un capacitor electrolítico de 10[uF] entre VCC y GND para proteger al microcontrolador de los transitorios al momento de conectar la interfaz y un capacitor cerámico de 0.1[uF] entre VCC y GND para quitar el ruido inducido por la longitud de los cables. El esquema de conexiones es el siguiente:
La configuración de fusibles es la siguiente:
El firmware lo pueden encontrar en la siguiente liga:
Firmware
Pueden grabar en el chip de un solo golpe tanto el firmware como los fusibles usando el avrdude, con un enunciado como el siguiente:
En mi caso, la línea de comando queda:
Ahh, como nota al pie, el botón SELECT del control no hace nada. En mis pruebas, reutilicé uno de los ATTINY25 que empleé en el adaptador a USB, por lo que su valor en el registro OSCCAL no era de 0xFF, sino de 0x57. Sin embargo, aún con un valor de 0xFF en OSCCAL no debería dar problemas.
Por si hay alguien que se pregunte qué hace esto, la respuesta es simple: sirve para conectar un control de SNES a la Dreamcast n_n. Ahora todo tiene sentido para los que se preguntaban ¿Para que necesita el pseudo-nerd llevar la frecuencia del control de SNES de sus cómodos 83.33[kHz] hasta 1[MHz] en una interfaz USB que sólo pide el estado de los botones 100 veces por segundo? El adaptador para USB en realidad sólo era el banco de pruebas de este proyecto.
MapleBUS es una interfaz de comunicación bidireccional digital half-duplex (es decir, en un instante dado sólo puede transmitir información en un sólo sentido) que es capaz de transmitir información a una tasa de 2[Mb/s]. A nivel físico, la interfaz cuenta con cinco terminales:
- 1.- SDCKA (Serial Data and ClocK A) Rojo
- 2.- VCC (5[V]) Azul
- 3.- Ground (0[V]) Negro
- 4.- Sense (0[V]) Verde
- 5.- SDCKB (Serial Data and ClocK B) Blanco
A nivel lógico, para la transferencia de información se emplean las terminales SDCKA y SDCKB. De forma general, cuando una de las terminales cambia su nivel de voltaje desde nivel alto (3.3[V]) a GND (es decir, ocurre un flanco de bajada), la interfaz detecta un ciclo de reloj y recoge como dato el nivel de voltaje que tiene la otra terminal. Por ejemplo, supongamos que tanto SDCKA como SDCKB tienen un nivel de 3.3[V], si SDCKA cambia de 3.3[V] a GND, la interfaz toma como dato el nivel de voltaje en SDCKB, en este caso 3.3[V] o "1 lógico". De esta forma se alternan los roles de las terminales SDCKA y SDCKB, ya que mientras una es "reloj", la otra es "dato". Esto permite que a pesar de que la frecuencia de cada señal es de aproximadamente 1[MHz], la interfaz tenga una frecuencia de 2[MHz].
Es una interfaz relativamente compleja de implementar en un microcontrolador, debido a que la mayoría de los microcontroladores de bajo costo sólo permiten leer niveles de voltaje en sus puertos. Algunos permiten detectar cambios de niveles o flancos (tanto de subida como de bajada), lo cual puede activar una interrupción y da la posibilidad al microcontrolador de actuar en consecuencia a los cambios de nivel. Sin embargo, el manejar interrupciones da lugar a un proceso relativamente complejo y lento que no es adecuado para una interfaz veloz.
Por ejemplo, supongamos un microcontrolador AVR trabajando a una frecuencia de 20[MHz] (el límite nominal para muchos ATTINY y ATMEGA), la detección de un flanco de bajada por alguna de las terminales INT0 o INT1 lleva 3 ciclos de reloj, el salto a la interrupción lleva 3 ciclos más, el recoger el dato del puerto lleva un ciclo, almacenarlo en alguna variable puede llevar uno o dos ciclos dependiendo del destino, volver al flujo del programa desde la interrupción lleva 4 ciclos de reloj. El procedimiento anterior consume 12 ciclos de reloj en el mejor de los casos (ya que en el ejemplo no se discrimina entre flanco de subida o bajada ni tampoco se ordena el bit en algún latch), lo cual es demasiado lento, ya que leer dos bits llevaría 24 ciclos de reloj. Dado que la interfaz transmite 2 bits cada [us] y el microcontrolador trabaja a 20 ciclos por [us], es posible notar el déficit de velocidad.
Es posible utilizar registros de corrimiento SIPO (Serial Input - Parallel Output) y latches para capturar los datos y retenerlos mientras el microcontrolador los procesa o leer los datos a través de la técnica de "polling". El polling consiste en monitorizar en un ciclo el estado de una variable o puerto y actuar acorde a él sin emplear interrupciones. Esta técnica es muy ineficiente, sin embargo es una alternativa viable en términos de velocidad y complejidad de circuito.
Gracias a la información otorgada por Marcus Comstedt y Sodor (A.K.A. leucemidus) fue posible implementar esta interfaz.
El primer (y hasta el momento único prototipo) utiliza sólo un ATTINY25... y nada más n_n. De hecho, pueden agregarse resistencias para proteger los pines conectados a la interfaz (47 o 68 omhs deben estar bien), un capacitor electrolítico de 10[uF] entre VCC y GND para proteger al microcontrolador de los transitorios al momento de conectar la interfaz y un capacitor cerámico de 0.1[uF] entre VCC y GND para quitar el ruido inducido por la longitud de los cables. El esquema de conexiones es el siguiente:
La configuración de fusibles es la siguiente:
- Low fuse: 0xE1
- High fuse: 0xDD
El firmware lo pueden encontrar en la siguiente liga:
Firmware
Pueden grabar en el chip de un solo golpe tanto el firmware como los fusibles usando el avrdude, con un enunciado como el siguiente:
avrdude -c "PONGA AQUI EL NOMBRE DE SU PROGRAMADOR" -p attiny25 -U flash:w:main.hex -U hfuse:w:0xdd:m -U lfuse:w:0xe1:m -U efuse:w:0xff:mEn mi caso, la línea de comando queda:
avrdude -c usbtiny -p attiny25 -U flash:w:main.hex -U hfuse:w:0xdd:m -U lfuse:w:0xe1:m -U efuse:w:0xff:mAhh, como nota al pie, el botón SELECT del control no hace nada. En mis pruebas, reutilicé uno de los ATTINY25 que empleé en el adaptador a USB, por lo que su valor en el registro OSCCAL no era de 0xFF, sino de 0x57. Sin embargo, aún con un valor de 0xFF en OSCCAL no debería dar problemas.
Por si hay alguien que se pregunte qué hace esto, la respuesta es simple: sirve para conectar un control de SNES a la Dreamcast n_n. Ahora todo tiene sentido para los que se preguntaban ¿Para que necesita el pseudo-nerd llevar la frecuencia del control de SNES de sus cómodos 83.33[kHz] hasta 1[MHz] en una interfaz USB que sólo pide el estado de los botones 100 veces por segundo? El adaptador para USB en realidad sólo era el banco de pruebas de este proyecto.
lunes, 1 de agosto de 2011
Información genérica (Parte 1).
Las vacaciones de verano están por concluir, por lo que los deadlines de los proyectos de vacaciones se acercan más con cada minuto que transcurre.
Antes de que pase más tiempo y se me olvide, les mostraré unos ejemplos de cómo se puede armar el adaptador de controles de SNES a USB que usa el ATTINY25.
Para este ejemplo se armó un cople con la carcasa de un cable defectuoso de un control genérico de SNES, al cual se le quitó el conector original y se le sustituyó con una placa con cinco pines soldados. La circuitería del adaptador se encuentra en el interior de la carcasa del conector DB9 que tiene en uno de sus extremos el cable USB que se conecta a la PC. Esta opción de armado es muy cómoda si es que se dispone de alguna extensión para controles de SNES, como las que se están vendiendo en MercadoLibre. Para el armado de este adaptador de utilizaron componentes convencionales, unidos entre sí por medio de cable calibre 24 y con todas las uniones aisladas. El microcontrolador está montado sobre una base de ocho terminales.
En este otro ejemplo el adaptador se encuentra contenido en una carcasa para conector DB25. En lo particular este es el montaje que más me agrada, ya que es liviano, rígido y es el más económico. El control de SNES se conecta a una serie de pines soldados a una placa de circuito impreso. Los pines empleados fueron retirados de un conector DB25 macho en desuso. Al parecer, pueden emplearse componentes convencionales para este montaje, sin embargo yo decidí emplear componentes SMD, que están soldados en la misma placa donde están soldados los pines. De esta forma, el montaje queda más compacto y resistente.
En este adaptador no se emplea ningún cople, ya que el control de SNES se conecta directamente a la entrada de la carcasa.
Para asegurar el contacto entre los pines y el conector del control, decidí moldear la forma del conector dentro de la carcasa con silicón. Si bien el acabado estético no es de lo mejor, funciona muy bien y evita conexiones en falso. Para unir el silicón a la carcasa del conector fundí el extremo con un encendedor, así el silicón no se sale del conector cuando se retira el control. El silicón empleado es el que se utiliza en manualidades (que se consigue en barras y se aplica con una pistola de calor), no del silicón industrial (que se aplica con un pistón, huele feo y que además resiste el calor).
Dependiendo de las herramientas y la destreza disponibles, es posible realizar adaptadores con acabados muy profesionales, los ejemplos anteriores me han dado muy buenos resultados, ya que son robustos (han soportado muy bien el uso rudo), baratos, fáciles de armar y no requieren de herramientas o materiales exóticos.
Antes de que pase más tiempo y se me olvide, les mostraré unos ejemplos de cómo se puede armar el adaptador de controles de SNES a USB que usa el ATTINY25.
 |
| El adaptador se encuentra dentro de la carcasa conectada al cable USB. |
Para este ejemplo se armó un cople con la carcasa de un cable defectuoso de un control genérico de SNES, al cual se le quitó el conector original y se le sustituyó con una placa con cinco pines soldados. La circuitería del adaptador se encuentra en el interior de la carcasa del conector DB9 que tiene en uno de sus extremos el cable USB que se conecta a la PC. Esta opción de armado es muy cómoda si es que se dispone de alguna extensión para controles de SNES, como las que se están vendiendo en MercadoLibre. Para el armado de este adaptador de utilizaron componentes convencionales, unidos entre sí por medio de cable calibre 24 y con todas las uniones aisladas. El microcontrolador está montado sobre una base de ocho terminales.
 |
| El adaptador se encuentra dentro de la carcasa para conector DB25. |
En este otro ejemplo el adaptador se encuentra contenido en una carcasa para conector DB25. En lo particular este es el montaje que más me agrada, ya que es liviano, rígido y es el más económico. El control de SNES se conecta a una serie de pines soldados a una placa de circuito impreso. Los pines empleados fueron retirados de un conector DB25 macho en desuso. Al parecer, pueden emplearse componentes convencionales para este montaje, sin embargo yo decidí emplear componentes SMD, que están soldados en la misma placa donde están soldados los pines. De esta forma, el montaje queda más compacto y resistente.
En este adaptador no se emplea ningún cople, ya que el control de SNES se conecta directamente a la entrada de la carcasa.
 |
| Se trató de vulcanizar con calor, y se ha derretido un poco X_x. |
Para asegurar el contacto entre los pines y el conector del control, decidí moldear la forma del conector dentro de la carcasa con silicón. Si bien el acabado estético no es de lo mejor, funciona muy bien y evita conexiones en falso. Para unir el silicón a la carcasa del conector fundí el extremo con un encendedor, así el silicón no se sale del conector cuando se retira el control. El silicón empleado es el que se utiliza en manualidades (que se consigue en barras y se aplica con una pistola de calor), no del silicón industrial (que se aplica con un pistón, huele feo y que además resiste el calor).
Dependiendo de las herramientas y la destreza disponibles, es posible realizar adaptadores con acabados muy profesionales, los ejemplos anteriores me han dado muy buenos resultados, ya que son robustos (han soportado muy bien el uso rudo), baratos, fáciles de armar y no requieren de herramientas o materiales exóticos.
viernes, 1 de julio de 2011
Una breve actualización.
Se han actualizado los códigos fuente y los firmwares de los adaptadores de SNES a USB para microcontroladores ATTINY25 y ATTINY2313. Pueden descargarlos desde el post donde se publicaron las primeras versiones o desde las siguientes ligas:
Adaptador con ATTINY25 (versión 2).
Adaptador con ATTINY2313 (versión 2).
Como no incluí un changelog (la verdad se me olvidó X_x), creo que es buen momento para comentar los cambios. A todos los que estén interesados en armar los adaptadores, les recomiendo encarecidamente que utilicen los firmwares más actuales.
La lista de cambios es la siguiente:
Después de una serie de pruebas, hay unos puntos que merecen ser aclarados, principalmente con el adaptador que utiliza el microcontrolador ATTINY25. Si se conecta el adaptador a un host de baja velocidad (USB 1.0 o 1.1), debe ser conectado ANTES que cualquier otro dispositivo USB, de lo contrario el oscilador interno no será capaz de calibrarse debido a los "downstream packets" del resto de los dispositivos. Si se conecta a un host USB de alta velocidad (USB 2.0), no debería presentarse dicho fenómeno.
El problema de los "downstream packets" es inherente al método de sincronización y hasta el momento no existe un método que permita librar el inconveniente. Existe una variante en la rutina de sincronización hecha por O. Tamura que tiene como objetivo librar de cierta manera el problema mencionado, sin embargo en mis pruebas no funcionó.
En mi opinión, considero que el adaptador que utiliza el ATTINY2313 es más confiable y una mejor opción para los principiantes (como yo n_n), además de que soporta dos controles de forma simultánea. En algún momento consideré en optimizar aún más el código y dar soporte a tres controles simultáneos, sin embargo ahora no parece una buena idea, debido a que los SNES se comercializaron en paquetes con uno o dos controles... por lo que tres controles (y más aún cuatro) me parece una exageración que sólo cobra sentido si se cuenta con cuatro controles (algo muy poco probable), cuatro jugadores (cuatro hijos, cuatro amigos o cuatro vagos n_n) y un juego que sea para cuatro jugadores simultáneos (Bomberman, FIFA, Queen of Hearts 99, Mario Kart 64, etc).
Adaptador con ATTINY25 (versión 2).
Adaptador con ATTINY2313 (versión 2).
Como no incluí un changelog (la verdad se me olvidó X_x), creo que es buen momento para comentar los cambios. A todos los que estén interesados en armar los adaptadores, les recomiendo encarecidamente que utilicen los firmwares más actuales.
La lista de cambios es la siguiente:
- Se realizaron optimizaciones en los ciclos.
- Se asignaron las variables globales a registros para incrementar la velocidad.
- Se asignó un nombre a los dispositivos (SNES Controller).
- Se incrementó la frecuencia de operación del control de 83.33kHz a 1MHz.
- Se realizó una limpieza en el código fuente.
- Para la versión ATTINY25: se ordenó el código y se retiraron los hacks del archivo usbconfig.h.
- Para la versión ATTINY25: se añadió una rutina para evitar escrituras innecesarias en la EEPROM, con el fin de incrementar su vida útil.
- Para la versión ATTINY25: la lectura de botones se hace por medio de la función Readbytes, para incrementar la legibilidad y portabilidad de las funciones.
Después de una serie de pruebas, hay unos puntos que merecen ser aclarados, principalmente con el adaptador que utiliza el microcontrolador ATTINY25. Si se conecta el adaptador a un host de baja velocidad (USB 1.0 o 1.1), debe ser conectado ANTES que cualquier otro dispositivo USB, de lo contrario el oscilador interno no será capaz de calibrarse debido a los "downstream packets" del resto de los dispositivos. Si se conecta a un host USB de alta velocidad (USB 2.0), no debería presentarse dicho fenómeno.
El problema de los "downstream packets" es inherente al método de sincronización y hasta el momento no existe un método que permita librar el inconveniente. Existe una variante en la rutina de sincronización hecha por O. Tamura que tiene como objetivo librar de cierta manera el problema mencionado, sin embargo en mis pruebas no funcionó.
En mi opinión, considero que el adaptador que utiliza el ATTINY2313 es más confiable y una mejor opción para los principiantes (como yo n_n), además de que soporta dos controles de forma simultánea. En algún momento consideré en optimizar aún más el código y dar soporte a tres controles simultáneos, sin embargo ahora no parece una buena idea, debido a que los SNES se comercializaron en paquetes con uno o dos controles... por lo que tres controles (y más aún cuatro) me parece una exageración que sólo cobra sentido si se cuenta con cuatro controles (algo muy poco probable), cuatro jugadores (cuatro hijos, cuatro amigos o cuatro vagos n_n) y un juego que sea para cuatro jugadores simultáneos (Bomberman, FIFA, Queen of Hearts 99, Mario Kart 64, etc).
miércoles, 29 de junio de 2011
Adaptador de control de SNES a USB (La burra vuelve al trigo).
Como parte de los experimentos de vacaciones, he estado poniendo a prueba el adaptador de controles de SNES a USB, para comprobar algunas teorías que venían rondando mi cabeza. Afortunadamente las pruebas han arrojado dos resultados muy buenos.
La primera prueba consistió en utilizar el ATTINY2313-10PU, en lugar de la versión de 20 MHz. Al principio me pareció que hacer esta prueba era una total pérdida de tiempo, considerando que la versión de 20 MHz es bastante fácil de conseguir en la Ciudad de México, sin embargo algunos amigos me han notificado que en muchos lugares la única versión disponible es la de 10 MHz. Después de hacer algunas pruebas bastante extensas (conseguir las 96 estrellas de Super Mario World), he llegado a la conclusión que el microcontrolador ATTINY2313-10PU sirve perfectamente para hacer el adaptador. Considero que hacer la prueba fue satisfactorio, debido a que en internet hay opiniones divididas acerca de utilizar un AVR con overclock. Por un lado hay quien afirma se puede hacer un overclock aun más extremo (35 MHz) sin notar anomalías en el funcionamiento de los dispositivos. Por otro lado está quien afirma que aplicar overclock a un AVR corrompe la EEPROM, el microcontrolador funciona erráticamente y por último el chip se quema. En mis pruebas, el microcontrolador no incrementó su temperatura, no sufrió de corrupción ni en la EEPROM ni en la FLASH y en ningún momento presentó falla. Cabe aclarar que el voltaje de alimentación fue de 5V, lo cual permite al microcontrolador operar a su máxima velocidad. Tiene sentido que el AVR se haya comportado bien, debido a que tanto la versión de 20 MHz como la de 10MHz tienen el mismo núcleo.
La otra prueba, fue incrementar la frecuencia de operación del propio control de SNES. La señal de reloj de entrada que suministra el SNES al control es de 83.33kHz. El pulso que sirve para habilitar el cerrojo (latch) tiene un periodo de 24us. Las pruebas que he realizado me han permitido elevar la frecuencia de operación del control a 500kHz. Para elevar aun más la frecuencia será necesario implementar macros personalizadas, debido a que las macros contenidas en la biblioteca delay.h solo permiten operar con microsegundos (incrementar la velocidad implicaría trabajar con nanosegundos). A 500kHz el control funciona perfectamente.
El control de NES contiene un chip MC14021, el control de SNES contiene un chip personalizado conocido como v520b, que es la versión "doble" del MC14021. Según la hoja de especificaciones del CD4021 (equivalente al MC14021), la frecuencia máxima de operación del circuito, cuando es alimentado con 5V es de 3.5MHz, siendo su frecuencia típica 2.5MHz. Al parecer es posible llevar al control a una frecuencia de operación de 2MHz considerando un margen de seguridad bastante amplio, por lo que esa será la meta en las pruebas subsecuentes.
La primera prueba consistió en utilizar el ATTINY2313-10PU, en lugar de la versión de 20 MHz. Al principio me pareció que hacer esta prueba era una total pérdida de tiempo, considerando que la versión de 20 MHz es bastante fácil de conseguir en la Ciudad de México, sin embargo algunos amigos me han notificado que en muchos lugares la única versión disponible es la de 10 MHz. Después de hacer algunas pruebas bastante extensas (conseguir las 96 estrellas de Super Mario World), he llegado a la conclusión que el microcontrolador ATTINY2313-10PU sirve perfectamente para hacer el adaptador. Considero que hacer la prueba fue satisfactorio, debido a que en internet hay opiniones divididas acerca de utilizar un AVR con overclock. Por un lado hay quien afirma se puede hacer un overclock aun más extremo (35 MHz) sin notar anomalías en el funcionamiento de los dispositivos. Por otro lado está quien afirma que aplicar overclock a un AVR corrompe la EEPROM, el microcontrolador funciona erráticamente y por último el chip se quema. En mis pruebas, el microcontrolador no incrementó su temperatura, no sufrió de corrupción ni en la EEPROM ni en la FLASH y en ningún momento presentó falla. Cabe aclarar que el voltaje de alimentación fue de 5V, lo cual permite al microcontrolador operar a su máxima velocidad. Tiene sentido que el AVR se haya comportado bien, debido a que tanto la versión de 20 MHz como la de 10MHz tienen el mismo núcleo.
La otra prueba, fue incrementar la frecuencia de operación del propio control de SNES. La señal de reloj de entrada que suministra el SNES al control es de 83.33kHz. El pulso que sirve para habilitar el cerrojo (latch) tiene un periodo de 24us. Las pruebas que he realizado me han permitido elevar la frecuencia de operación del control a 500kHz. Para elevar aun más la frecuencia será necesario implementar macros personalizadas, debido a que las macros contenidas en la biblioteca delay.h solo permiten operar con microsegundos (incrementar la velocidad implicaría trabajar con nanosegundos). A 500kHz el control funciona perfectamente.
El control de NES contiene un chip MC14021, el control de SNES contiene un chip personalizado conocido como v520b, que es la versión "doble" del MC14021. Según la hoja de especificaciones del CD4021 (equivalente al MC14021), la frecuencia máxima de operación del circuito, cuando es alimentado con 5V es de 3.5MHz, siendo su frecuencia típica 2.5MHz. Al parecer es posible llevar al control a una frecuencia de operación de 2MHz considerando un margen de seguridad bastante amplio, por lo que esa será la meta en las pruebas subsecuentes.
jueves, 23 de junio de 2011
Wireless o Wirelazy?
Después de un agobiante semestre en la Facultad, una de las mejores formas de despejar la mente y pasar un rato ameno (al menos de las que yo conozco) es jugar videojuegos. Estas dos semanas de vacaciones, he estado jugando Sakura Wars ~ So Long my Love para PS2. Se trata de un juego híbrido entre un RPG táctico y un simulador de citas, que en lo personal me agrada mucho. Es un juego largo, que ofrece seis rutas en total para obtener algún final, cada ruta tiene una duración promedio de veinte horas, las cuales pueden ser más si lees todos los diálogos. Debido a que no se trata de un juego de aventuras o de acción, se puede disfrutar cómodamente desde un sillón con un control inalámbrico que usaremos prácticamente sólo para avanzar los diálogos e introducir unos cuantos comandos cuando el juego los requiere (como la mayoría de los RPG).
Para jugar, utilizo un control Pelican Chameleon Wireless, el cual ya tiene bastantes años de uso, y también ya lleva bastantes reparaciones menores. En términos generales es un buen control, por lo menos para jugar RPGs, pero tiene unos cuantos detalles que a veces pueden ser algo molestos. El primero es el material del que está hecho, es un tipo de plástico transparente bastante quebradizo, si el control sufre una caída de apenas 40 cms, ten por seguro que alguna parte se habrá estrellado o roto. El segundo es que los potenciómetros de las palancas analógicas son de una pésima calidad, después de unos meses de uso se desgastan y comienzan a marcar valores de resistencia erráticos. Lo anterior le quita precisión al control, y además suele tener al control en estado de transmisión prácticamente de forma permanente. El tercer detalle que tiene es que algunos de los controles consumen mucha batería.
De los detalles del control, el que me resulta más molesto es el del consumo de las baterías debido a que los RPGs suelen exigir largas jornadas de juego. Pero por suerte, todo tiene solución. En las especificaciones de los controles inalámbricos suelen presumir la tecnología 2.4 Ghz, el alcance de 10 pies, la respuesta del control pero omiten datos técnicos que podrían ayudarnos a evaluar de forma más objetiva al control. Entre los datos que suelen omitirse (incluso en las hojas de especificaciones de los controles) es la corriente que demandan los controles. Poseeo tres tipos de controles inalámbricos, el Pelican que ya mencioné, un Dreamgear Lavaglow y el control inalámbrico del XBOX 360 y ninguno ofrece la información eléctrica mínima. En el apartado de consumo de energía ponen un enunciado de burla como: "Hasta 300 horas de juego" (en el caso del Pelican) o "Hasta 40 horas de juego" (en el caso del control del XBOX 360), lo cual es completamente inválido si le colocas al control pilas Rocket y que más que información parecen frases para comercial.
Multímetro en mano, me decidí a averiguar de una vez por todas porqué las empresas no quieren dar a conocer de forma clara el consumo de sus productos. El control de XBOX 360, en modo de operación pasiva (es decir, sin presionar teclas ni vibración) consume 70 mA, al utilizar la vibración, el transitorio de corriente se sale de la escala de los 200 mA. El Dreamgear consume en modo de operación sin los LED encendidos 20 mA. El Pelican consume en operación pasiva 3 mA, mientras que en operación activa (con botones presionados) consume 17 mA. En este caso, podemos ver que el control que funciona de forma más eficiente es el Pelican.
Uno de mis controles Pelican tenía un error de fabrica, ya que la resistencia limitadora de corriente para el LED que indica la actividad del control, en vez de tener un valor de 1000 Ohms, tenía un valor de 100 Ohms, lo cual incrementaba de forma notable el consumo del control.
Para corregir el error, y de paso ganar un poco más de autonomía en las pilas, cambié la resistencia por una de 3300 Ohms, lo cual disminuye el brillo del LED de forma notable, sin llegar a dificultar su visibilidad. Con dicha modificación el consumo del control en operación activa es de 15.24 mA, con lo cual se reduce su consumo en un 10%. A continuación pongo una tabla donde se muestran la duración de un set de baterías de 2000 [mAh] en perfecto estado en cada uno de los controles. La duración máxima se ha calculado de acuerdo a las lecturas de corriente en estado pasivo de cada control, mientras que la duración promedio se ha medido jugando con cada control.
Como podemos ver, los consumos publicitados por las marcas de los controles son un truco publicitario bastante barato.
Para jugar, utilizo un control Pelican Chameleon Wireless, el cual ya tiene bastantes años de uso, y también ya lleva bastantes reparaciones menores. En términos generales es un buen control, por lo menos para jugar RPGs, pero tiene unos cuantos detalles que a veces pueden ser algo molestos. El primero es el material del que está hecho, es un tipo de plástico transparente bastante quebradizo, si el control sufre una caída de apenas 40 cms, ten por seguro que alguna parte se habrá estrellado o roto. El segundo es que los potenciómetros de las palancas analógicas son de una pésima calidad, después de unos meses de uso se desgastan y comienzan a marcar valores de resistencia erráticos. Lo anterior le quita precisión al control, y además suele tener al control en estado de transmisión prácticamente de forma permanente. El tercer detalle que tiene es que algunos de los controles consumen mucha batería.
De los detalles del control, el que me resulta más molesto es el del consumo de las baterías debido a que los RPGs suelen exigir largas jornadas de juego. Pero por suerte, todo tiene solución. En las especificaciones de los controles inalámbricos suelen presumir la tecnología 2.4 Ghz, el alcance de 10 pies, la respuesta del control pero omiten datos técnicos que podrían ayudarnos a evaluar de forma más objetiva al control. Entre los datos que suelen omitirse (incluso en las hojas de especificaciones de los controles) es la corriente que demandan los controles. Poseeo tres tipos de controles inalámbricos, el Pelican que ya mencioné, un Dreamgear Lavaglow y el control inalámbrico del XBOX 360 y ninguno ofrece la información eléctrica mínima. En el apartado de consumo de energía ponen un enunciado de burla como: "Hasta 300 horas de juego" (en el caso del Pelican) o "Hasta 40 horas de juego" (en el caso del control del XBOX 360), lo cual es completamente inválido si le colocas al control pilas Rocket y que más que información parecen frases para comercial.
Multímetro en mano, me decidí a averiguar de una vez por todas porqué las empresas no quieren dar a conocer de forma clara el consumo de sus productos. El control de XBOX 360, en modo de operación pasiva (es decir, sin presionar teclas ni vibración) consume 70 mA, al utilizar la vibración, el transitorio de corriente se sale de la escala de los 200 mA. El Dreamgear consume en modo de operación sin los LED encendidos 20 mA. El Pelican consume en operación pasiva 3 mA, mientras que en operación activa (con botones presionados) consume 17 mA. En este caso, podemos ver que el control que funciona de forma más eficiente es el Pelican.
Uno de mis controles Pelican tenía un error de fabrica, ya que la resistencia limitadora de corriente para el LED que indica la actividad del control, en vez de tener un valor de 1000 Ohms, tenía un valor de 100 Ohms, lo cual incrementaba de forma notable el consumo del control.
Para corregir el error, y de paso ganar un poco más de autonomía en las pilas, cambié la resistencia por una de 3300 Ohms, lo cual disminuye el brillo del LED de forma notable, sin llegar a dificultar su visibilidad. Con dicha modificación el consumo del control en operación activa es de 15.24 mA, con lo cual se reduce su consumo en un 10%. A continuación pongo una tabla donde se muestran la duración de un set de baterías de 2000 [mAh] en perfecto estado en cada uno de los controles. La duración máxima se ha calculado de acuerdo a las lecturas de corriente en estado pasivo de cada control, mientras que la duración promedio se ha medido jugando con cada control.
| Tiempo promedio de duración de baterías (2000[mAh]) | ||
|---|---|---|
| Control | Mayor duración posible | Duración promedio |
| XBOX 360 Wireless (X360) | 28 horas | 16 horas |
| Pelican Chameleon Wireless (PS2) | 330 horas | 130 horas |
| Dreamgear LavaGlow Wireless (PS2) | 100 horas | 80 horas |
Como podemos ver, los consumos publicitados por las marcas de los controles son un truco publicitario bastante barato.
martes, 7 de junio de 2011
Entre cartones y cartoons
En esta entrada aun no publicaré nada sobre los proyectos, que andan avanzando a un ritmo un poco más lento que el previsto, sin embargo, la meta de tenerlos listos en julio aún se ve bastante realista. Mi investigación reciente me permitió percatarme de un detalle que estaba pasando por alto la primera vez que analicé la viabilidad del proyecto y ahora estoy viendo la forma de solventarlo, usando la menor cantidad de memoria posible.
Esta semana cayó en mis manos un Sega Dreamcast con un detalle de lectura de discos. Normalmente, los problemas de lectura de discos en la mayoría de las consolas se deben a la suciedad que se acumula en la parte interna del pick up de la unidad láser, a la suciedad externa en el lente de enfoque o al desgaste del diodo láser. Sin embargo este Dreamcast sufría de un problema no tan común. El pick up del láser se desplaza desde el centro del disco hasta la orilla, para leer los datos contenidos en él, mientras el disco gira a una velocidad determinada por la velocidad de la unidad lectora en conjunto. Pues bien, resulta que el Dreamcast que cayó en mis manos tenía un defecto en la transmisión del motor que mueve al pick up, ya que hacía un ruido agudo al tratar de desplazarse, además de que después de moverse por cerca de dos minutos, el pick up ya no podía moverse más. Mi primera idea fue que quizás el motor estaba desgastado y debía ser reemplazado, sin embargo, mis pruebas mostraron que el motor se encontraba en perfecto estado. Procedí a desmontar la transmisión, limpiar los engranes, lubricarlos y volver a montar todo en su sitio. Lo anterior hizo que los ruidos tuvieran una menor intensidad, además el pick up se movía con mayor libertad... pero aún así se podían percibir anomalías en el funcionamiento de la unidad lectora. Procedí a buscar entre mis cosas viejas una refacción de la transmisión de la unidad láser, la cual encontré después de mover un montón de cosas. Procedí a colocar la refacción (que si no mal recuerdo procedía de un Dreamcast edición SEGA Sports) y la unidad lectora funcionó como nueva.
En el proceso de buscar la refacción que salvó la vida del Dreamcast encontré la caja de un procesador AMD Sempron. Dicha caja no contiene un procesador... sino mi colección de tarjetas de Magic ~ The Gathering, Yu-Gi-Oh! y Sakura Card Captor TCG. Recuerdo que hace unos cuatro o cinco años esas tarjetitas eran una parte importante de mi rutina diaria, debido a que jugaba con ellas con algunos de mis amigos, además de que solía comprar aquellas que tenían dibujos padres o las que podían fortalecer mi mazo y darme ventaja al jugar. En aquél entonces las cosas en mi vida eran muy distintas, ya que trabajaba medio día (lo que me permitía tener cierta solvencia económica), gastaba muy poco tiempo y dinero en el transporte público, ya que vivía cerca del centro de la ciudad, y en la escuela prácticamente no hacía otra cosa mas que ver anime, platicar con mis amigos, jugar videojuegos y juegos de tarjetas (o sea, un NEET).
Por pura curiosidad abrí la caja, para ver a grosso modo qué contenía, ya que la verdad olvidé qué tarjetas tenía. Una inspección rápida reveló dos cosas que me perturbaron: la primera es que las tarjetas están en estado de conservación perfecto, ninguna tiene ni un doblez, mancha o muestra de abuso. La segunda es que la mayoría de las tarjetas son del tipo rara. Recordé entonces que en algún momento me deshice de las tarjetas comunes que tenía, lo que no recuerdo es si las regalé, vendí o simplemente las tiré a la basura. Al ver esas tarjetas, me sentí bastante raro. La verdad, me cuesta ver cómo es que estos pedazos de cartón me llegaron a apasionar a un punto tal, que invertí bastante dinero y tiempo en ellas. Aunque debo admitir que jugar con mis amigos fue divertido.
Entre las cartas de Yu-Gi-Oh! (que fueron a las que les dediqué más tiempo y dinero) que aparecieron en la caja sobresalen un par de Buster Blader, un Dark Paladin, un par de Dark Magician Girl, una Cyber Harpie Lady, entre otras no tan relevantes como Red Eyes Black Dragon, XYZ Dragon Cannon, Berserk Dragon, Dark Elf, etc, etc. Por pura curiosidad busqué en MercadoLibre el precio de algunas de ellas, para ver en cuánto se están cotizando... y cual fue mi sorpresa al ver que el precio de muchas tarjetas es el doble o el triple del que pagué por ellas en su momento. Aunque eso fue lo que menos me sorprendió, pues al fin y al cabo yo podría publicar un Sega Dreamcast recién reparado a 800 pesos, y difícilmente alguien mordería el anzuelo. Lo realmente sorprendente es que varias de las tarjetas llevaban dos o tres ventas.
Al parecer, Yu-Gi-Oh! sigue estando vigente y algunas personas están tratando de ampliar sus colecciones con tarjetas viejas. Mientras tanto, las mías esperarán la hora del duelo, dentro de una caja de microprocesador...
Esta semana cayó en mis manos un Sega Dreamcast con un detalle de lectura de discos. Normalmente, los problemas de lectura de discos en la mayoría de las consolas se deben a la suciedad que se acumula en la parte interna del pick up de la unidad láser, a la suciedad externa en el lente de enfoque o al desgaste del diodo láser. Sin embargo este Dreamcast sufría de un problema no tan común. El pick up del láser se desplaza desde el centro del disco hasta la orilla, para leer los datos contenidos en él, mientras el disco gira a una velocidad determinada por la velocidad de la unidad lectora en conjunto. Pues bien, resulta que el Dreamcast que cayó en mis manos tenía un defecto en la transmisión del motor que mueve al pick up, ya que hacía un ruido agudo al tratar de desplazarse, además de que después de moverse por cerca de dos minutos, el pick up ya no podía moverse más. Mi primera idea fue que quizás el motor estaba desgastado y debía ser reemplazado, sin embargo, mis pruebas mostraron que el motor se encontraba en perfecto estado. Procedí a desmontar la transmisión, limpiar los engranes, lubricarlos y volver a montar todo en su sitio. Lo anterior hizo que los ruidos tuvieran una menor intensidad, además el pick up se movía con mayor libertad... pero aún así se podían percibir anomalías en el funcionamiento de la unidad lectora. Procedí a buscar entre mis cosas viejas una refacción de la transmisión de la unidad láser, la cual encontré después de mover un montón de cosas. Procedí a colocar la refacción (que si no mal recuerdo procedía de un Dreamcast edición SEGA Sports) y la unidad lectora funcionó como nueva.
En el proceso de buscar la refacción que salvó la vida del Dreamcast encontré la caja de un procesador AMD Sempron. Dicha caja no contiene un procesador... sino mi colección de tarjetas de Magic ~ The Gathering, Yu-Gi-Oh! y Sakura Card Captor TCG. Recuerdo que hace unos cuatro o cinco años esas tarjetitas eran una parte importante de mi rutina diaria, debido a que jugaba con ellas con algunos de mis amigos, además de que solía comprar aquellas que tenían dibujos padres o las que podían fortalecer mi mazo y darme ventaja al jugar. En aquél entonces las cosas en mi vida eran muy distintas, ya que trabajaba medio día (lo que me permitía tener cierta solvencia económica), gastaba muy poco tiempo y dinero en el transporte público, ya que vivía cerca del centro de la ciudad, y en la escuela prácticamente no hacía otra cosa mas que ver anime, platicar con mis amigos, jugar videojuegos y juegos de tarjetas (o sea, un NEET).
Por pura curiosidad abrí la caja, para ver a grosso modo qué contenía, ya que la verdad olvidé qué tarjetas tenía. Una inspección rápida reveló dos cosas que me perturbaron: la primera es que las tarjetas están en estado de conservación perfecto, ninguna tiene ni un doblez, mancha o muestra de abuso. La segunda es que la mayoría de las tarjetas son del tipo rara. Recordé entonces que en algún momento me deshice de las tarjetas comunes que tenía, lo que no recuerdo es si las regalé, vendí o simplemente las tiré a la basura. Al ver esas tarjetas, me sentí bastante raro. La verdad, me cuesta ver cómo es que estos pedazos de cartón me llegaron a apasionar a un punto tal, que invertí bastante dinero y tiempo en ellas. Aunque debo admitir que jugar con mis amigos fue divertido.
Entre las cartas de Yu-Gi-Oh! (que fueron a las que les dediqué más tiempo y dinero) que aparecieron en la caja sobresalen un par de Buster Blader, un Dark Paladin, un par de Dark Magician Girl, una Cyber Harpie Lady, entre otras no tan relevantes como Red Eyes Black Dragon, XYZ Dragon Cannon, Berserk Dragon, Dark Elf, etc, etc. Por pura curiosidad busqué en MercadoLibre el precio de algunas de ellas, para ver en cuánto se están cotizando... y cual fue mi sorpresa al ver que el precio de muchas tarjetas es el doble o el triple del que pagué por ellas en su momento. Aunque eso fue lo que menos me sorprendió, pues al fin y al cabo yo podría publicar un Sega Dreamcast recién reparado a 800 pesos, y difícilmente alguien mordería el anzuelo. Lo realmente sorprendente es que varias de las tarjetas llevaban dos o tres ventas.
Al parecer, Yu-Gi-Oh! sigue estando vigente y algunas personas están tratando de ampliar sus colecciones con tarjetas viejas. Mientras tanto, las mías esperarán la hora del duelo, dentro de una caja de microprocesador...
sábado, 28 de mayo de 2011
Ya regresó aquél por quien lloraban!!
Luego de una larga ausencia, estoy acá, dándome una vuelta para no dejar tan abandonado el changarro.
En esta entrada no comentaré acerca de los proyectos que se han estado gestando en este par de meses, ya que el plan es terminar en julio el prototipo más ambicioso que he diseñado hasta la fecha. Lo que si puedo adelantar es que subiré algunos proyectos que hice para la escuela y que de verdad me parecen muy interesantes.
Este último mes ha estado muy acelerado, la escuela a reclamado tiempo que no le había dedicado desde aquellos lejanos años de la primaria. El día lunes de la semana pasada tuve un par de horas libres entre las horas de clase. Debido a que ya estaba harto de estar estudiando en la biblioteca y de probar proyectos en el laboratorio abierto decidí dar una caminata por el Circuito Escolar de C.U. para matar el tiempo. Al pasar frente al puesto de revistas que está en la puerta de la Fac. de Odontología, me dieron ganas de comprar una revista para amenizar el rato. Tenía años que no me paraba enfrente de un puesto de revistas para escoger alguna, ya que suelo comprar la POWER Users por costumbre (costumbre que he abandonado a partir de este mes).
Mi primera sorpresa fue notar que los precios de la mayoría de las revistas es muy alto. Ante esta circunstancia, me establecí un tope de precio de 30 pesos, ya que en verdad solo quería leer algo para despejar un poco mi mente (que estaba completamente trastornada después de tantos proyectos). En eso estaba cuando una revista llamó mi atención: la revista Club Nintendo año 20, número 5, con portada conmemorativa por los 20 años de Sonic.
La revista cuesta 27 pesos, por lo que sin pensarlo mucho decidí comprarla y ver qué información tenía. En mi infancia coleccioné la revista Club Nintendo, desde el número 1 del año 1 hasta por ahí del año 6 o 7... la verdad ya no recuerdo cuál fue la última que compré. Al ver que la revista ya cumplió 19 años, tuve una revelación... realmente ya estoy viejo X_x! Con revista en mano, me senté a la sombra de la Torre 2 de Humanidades y con un hermoso atardecer me dispuse a leer la revista como en los viejos tiempos, es decir, con la pura intención de entretenerme.
Ahh, como paréntesis, si pueden darse una vuelta por la página de ClubNientiendo pueden encontrar reseñas de revistas Club Nintendo viejas hechas a posteriori y la mayoría de ellas son muy divertidas.
La verdad, la revista ha cambiado mucho en este tiempo, así como también lo ha hecho la tecnología, el público, la economía y los usuarios de videojuegos. El artículo de Sonic no estuvo tan interesante como podría haber estado, ya que en su mayoría es meramente descriptivo de lo que cualquiera percibe al jugar o ver un juego de Sonic. Cuentan en el artículo un par de anécdotas sin importancia sobre el origen del personaje, pero se enfocan mucho más en los juegos de Sonic en plataformas de Nintendo... que desgraciadamente han sido los que menos me han gustado. Algo que se nota en toda la revista es la gran emoción que les da a los colaboradores el poder hablar de juegos como Blazblue, Dead or Alive o Super Street Fighter 4 gracias al lanzamiento de dichos títulos en la N3DS. Se ve que la sequía de franquicias de juegos de peleas en consolas de Nintendo ha estado fuerte.
Por ahí también pusieron un artículo sobre el anime de Mazinger Z que poco tiene que ver con videojuegos de Nintendo. También trae un artículo bastante genérico sobre los viajes en el tiempo en el cine, los libros y por supuesto, los videojuegos de Nintendo.
Recuerdo que en sus inicios, Club Nintendo le dedicó una cantidad monstruosa de páginas y de tinta al juego de Street Fighter 2 (y sus mejoras), circunstancia que al parecer tratan de repetir con el juego de Super Street Fighter 4. Sin embargo, la circunstancia no es la misma que se vivió a principios de la década de los noventas, donde la versión más padre de Street Fighter 2 era siempre la versión de SNES. En esta ocasión, la versión para la consola de Nintendo es inferior respecto a sus contrapartes de XBOX 360 y PS3, debido a que es para una consola portátil. Cuenta con efecto 3D, pero tiene una resolución muy pobre, fondos sin movimiento y carece de muchos de los efectos especiales que se ven en las otras versiones.
Sin duda alguna, lo que de verdad se nota que le está afectando a Club Nintendo es la internet. La información en la revista esta atrasada no por un mes, sino por lo menos por cuatro meses. Además, ante las inquietudes de los lectores acerca de los múltiples rumores que hay sobre lanzamientos de juegos, ofertas o actualizaciones, la revista se limita a responder el clásico "Nintendo aún no ha confirmado nada, pero en cuanto lo haga te lo haremos saber"... como seis meses después.
La verdad, siento que la revista no ofrece mucho a sus lectores. Quizás eso a sido siempre así, pero en la era pre-internet era más difícil darse cuenta de ello.
En esta entrada no comentaré acerca de los proyectos que se han estado gestando en este par de meses, ya que el plan es terminar en julio el prototipo más ambicioso que he diseñado hasta la fecha. Lo que si puedo adelantar es que subiré algunos proyectos que hice para la escuela y que de verdad me parecen muy interesantes.
Este último mes ha estado muy acelerado, la escuela a reclamado tiempo que no le había dedicado desde aquellos lejanos años de la primaria. El día lunes de la semana pasada tuve un par de horas libres entre las horas de clase. Debido a que ya estaba harto de estar estudiando en la biblioteca y de probar proyectos en el laboratorio abierto decidí dar una caminata por el Circuito Escolar de C.U. para matar el tiempo. Al pasar frente al puesto de revistas que está en la puerta de la Fac. de Odontología, me dieron ganas de comprar una revista para amenizar el rato. Tenía años que no me paraba enfrente de un puesto de revistas para escoger alguna, ya que suelo comprar la POWER Users por costumbre (costumbre que he abandonado a partir de este mes).
Mi primera sorpresa fue notar que los precios de la mayoría de las revistas es muy alto. Ante esta circunstancia, me establecí un tope de precio de 30 pesos, ya que en verdad solo quería leer algo para despejar un poco mi mente (que estaba completamente trastornada después de tantos proyectos). En eso estaba cuando una revista llamó mi atención: la revista Club Nintendo año 20, número 5, con portada conmemorativa por los 20 años de Sonic.
La revista cuesta 27 pesos, por lo que sin pensarlo mucho decidí comprarla y ver qué información tenía. En mi infancia coleccioné la revista Club Nintendo, desde el número 1 del año 1 hasta por ahí del año 6 o 7... la verdad ya no recuerdo cuál fue la última que compré. Al ver que la revista ya cumplió 19 años, tuve una revelación... realmente ya estoy viejo X_x! Con revista en mano, me senté a la sombra de la Torre 2 de Humanidades y con un hermoso atardecer me dispuse a leer la revista como en los viejos tiempos, es decir, con la pura intención de entretenerme.
Ahh, como paréntesis, si pueden darse una vuelta por la página de ClubNientiendo pueden encontrar reseñas de revistas Club Nintendo viejas hechas a posteriori y la mayoría de ellas son muy divertidas.
La verdad, la revista ha cambiado mucho en este tiempo, así como también lo ha hecho la tecnología, el público, la economía y los usuarios de videojuegos. El artículo de Sonic no estuvo tan interesante como podría haber estado, ya que en su mayoría es meramente descriptivo de lo que cualquiera percibe al jugar o ver un juego de Sonic. Cuentan en el artículo un par de anécdotas sin importancia sobre el origen del personaje, pero se enfocan mucho más en los juegos de Sonic en plataformas de Nintendo... que desgraciadamente han sido los que menos me han gustado. Algo que se nota en toda la revista es la gran emoción que les da a los colaboradores el poder hablar de juegos como Blazblue, Dead or Alive o Super Street Fighter 4 gracias al lanzamiento de dichos títulos en la N3DS. Se ve que la sequía de franquicias de juegos de peleas en consolas de Nintendo ha estado fuerte.
Por ahí también pusieron un artículo sobre el anime de Mazinger Z que poco tiene que ver con videojuegos de Nintendo. También trae un artículo bastante genérico sobre los viajes en el tiempo en el cine, los libros y por supuesto, los videojuegos de Nintendo.
Recuerdo que en sus inicios, Club Nintendo le dedicó una cantidad monstruosa de páginas y de tinta al juego de Street Fighter 2 (y sus mejoras), circunstancia que al parecer tratan de repetir con el juego de Super Street Fighter 4. Sin embargo, la circunstancia no es la misma que se vivió a principios de la década de los noventas, donde la versión más padre de Street Fighter 2 era siempre la versión de SNES. En esta ocasión, la versión para la consola de Nintendo es inferior respecto a sus contrapartes de XBOX 360 y PS3, debido a que es para una consola portátil. Cuenta con efecto 3D, pero tiene una resolución muy pobre, fondos sin movimiento y carece de muchos de los efectos especiales que se ven en las otras versiones.
Sin duda alguna, lo que de verdad se nota que le está afectando a Club Nintendo es la internet. La información en la revista esta atrasada no por un mes, sino por lo menos por cuatro meses. Además, ante las inquietudes de los lectores acerca de los múltiples rumores que hay sobre lanzamientos de juegos, ofertas o actualizaciones, la revista se limita a responder el clásico "Nintendo aún no ha confirmado nada, pero en cuanto lo haga te lo haremos saber"... como seis meses después.
La verdad, siento que la revista no ofrece mucho a sus lectores. Quizás eso a sido siempre así, pero en la era pre-internet era más difícil darse cuenta de ello.
martes, 5 de abril de 2011
Adaptador de control de SNES a USB (Paso a paso).
ADVERTENCIA: esta entrada de blog puede contener información que puede resultar perturbadora para videojugadores que no aprecien el "retrogamming".
Después de unos días de investigación, desarrollé dos mejoras de los adaptadores de Hobbyelektronik, uno que emplea el microcontrolador ATTINY25 y otro que utiliza el ATTINY2313. Antes que nada quiero agradecer y dar crédito a las personas que con sus proyectos, apoyo y asesoría colaboraron a la realización de estas necedades: Raphaël Assénat, Christof Rueß, Primož Kranjec, Paul Qureshi, Chris Judevine, andreq, ChaN y Dash.
El adaptador que emplea el ATTINY25 soporta un control de SNES, mientras que el adaptador que utiliza el ATTINY2313 soporta dos controles.
Hechas las aclaraciones pertinentes, pasemos a la lista de compras:
Para el adaptador de un control con el ATTINY25 se necesita:
Para el adaptador de un control con el ATTINY2313 se necesita:
Para ambos proyectos:
El adaptador con el ATTINY25 es tan compacto que puede armarse soldando directamente los componentes y colocando todo en un bloque de plástico o en la carcasa de un conector DB9.
El adaptador con el ATTINY2313 requiere de un circuito impreso y un gabinete, el cual puede ser un bloque de plástico tipo LEGO.
Los diagramas empleados son los siguientes:
Para el proyecto con el ATTINY25, los fusibles quedan configurados de la siguiente forma:
Para el proyecto con el ATTINY2313, los fusibles quedan configurados de la siguiente forma:
Hay que precisar que el firmware con el ATTINY25 cuenta con calibración automática del oscilador. Ambos firmwares ocupan el PID/VID de los proyectos de Hobbyelektronik, debido a que son derivados de los mismos. Los dispositivos han sido probados en Linux y Windows XP. Por cuestiones de espacio en memoria estos dispositivos no tienen asignado un nombre, por lo que al conectarlos en Windows XP y entrar en la opción de Dispositivos de juego, muy probablemente veremos un caracter raro en vez del nombre de un gamepad. Si deseas que en vez de esos caracteres raros aparezca un nombre más cool, es posible modificar el registro de Windows para arreglar ese detalle, basta con copiar la siguiente información en un archivo de texto y guardarlo como oemname.reg
Dar doble click sobre el archivo oemname.reg, reiniciar la computadora y al conectar de nuevo el adaptador, aparecerá con el nombre Super NES Controller. Pueden ponerle el nombre que quieran, sin embargo, el nombre del dispositivo que aparece en el control es:
Los códigos fuente y firmwares compilados están en las siguientes ligas:
Adaptador con ATTINY25
Adaptador con ATTINY2313
Después de unos días de investigación, desarrollé dos mejoras de los adaptadores de Hobbyelektronik, uno que emplea el microcontrolador ATTINY25 y otro que utiliza el ATTINY2313. Antes que nada quiero agradecer y dar crédito a las personas que con sus proyectos, apoyo y asesoría colaboraron a la realización de estas necedades: Raphaël Assénat, Christof Rueß, Primož Kranjec, Paul Qureshi, Chris Judevine, andreq, ChaN y Dash.
El adaptador que emplea el ATTINY25 soporta un control de SNES, mientras que el adaptador que utiliza el ATTINY2313 soporta dos controles.
Hechas las aclaraciones pertinentes, pasemos a la lista de compras:
Para el adaptador de un control con el ATTINY25 se necesita:
- Un ATTINY25-20PU (DIP).
- Una base DIP de 8 pines.
- Una resistencia de 2.2 KOhm a 0.25 Watt.
Para el adaptador de un control con el ATTINY2313 se necesita:
- Un ATTINY2313-20PU (DIP).
- Una base DIP de 20 pines.
- Una resistencia de 1.5 KOhm a 0.25 Watt.
- Dos capacitores cerámicos de 47, 33 o 27 pF (tienen impresos los números 47, 33 o 27).
- Un cristal de cuarzo de 12 MHz.
- Una placa para circuito impreso.
Para ambos proyectos:
- Cables.
- Dos diodos zener de 3.6 Volts.
- Dos resistencias de 47 o 68 Ohms a 0.25 Watt.
- Un capacitor electrolitico de 10 uF (opcional).
- Un capacitor cerámico de 0.1 uF (opcional)(tiene impreso el número 104)
- Un cable USB tipo A.
- Coples para control de SNES.
- Un programador de microcontroladores AVR.
El adaptador con el ATTINY25 es tan compacto que puede armarse soldando directamente los componentes y colocando todo en un bloque de plástico o en la carcasa de un conector DB9.
El adaptador con el ATTINY2313 requiere de un circuito impreso y un gabinete, el cual puede ser un bloque de plástico tipo LEGO.
Los diagramas empleados son los siguientes:
 |
| Adaptador de un control de SNES a USB con ATTINY25 |
 |
| Adaptador para dos controles de SNES a USB con ATTINY2313 |
Para el proyecto con el ATTINY25, los fusibles quedan configurados de la siguiente forma:
- Low fuse: 0xE1
- High fuse: 0xDD
Para el proyecto con el ATTINY2313, los fusibles quedan configurados de la siguiente forma:
- Low fuse: 0xDF
- High fuse: 0x99
Hay que precisar que el firmware con el ATTINY25 cuenta con calibración automática del oscilador. Ambos firmwares ocupan el PID/VID de los proyectos de Hobbyelektronik, debido a que son derivados de los mismos. Los dispositivos han sido probados en Linux y Windows XP. Por cuestiones de espacio en memoria estos dispositivos no tienen asignado un nombre, por lo que al conectarlos en Windows XP y entrar en la opción de Dispositivos de juego, muy probablemente veremos un caracter raro en vez del nombre de un gamepad. Si deseas que en vez de esos caracteres raros aparezca un nombre más cool, es posible modificar el registro de Windows para arreglar ese detalle, basta con copiar la siguiente información en un archivo de texto y guardarlo como oemname.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_4242&PID_E131]
"OEMName"="Super NES Controller"
"OEMData"=hex:20,00,00,10,08,00,00,00
Dar doble click sobre el archivo oemname.reg, reiniciar la computadora y al conectar de nuevo el adaptador, aparecerá con el nombre Super NES Controller. Pueden ponerle el nombre que quieran, sin embargo, el nombre del dispositivo que aparece en el control es:
Super NES Controller
MODEL NO. SNS-005
Los códigos fuente y firmwares compilados están en las siguientes ligas:
Adaptador con ATTINY25
Adaptador con ATTINY2313
Adaptador de control de SNES a USB (Round 2).
Con más confianza que conocimiento de causa compré un par de microcontroladores ATTINY25-20PU, a un precio unitario de 40 pesos mexicanos. Mi escaso conocimiento sobre la programación de los microcontroladores (no es lo mismo diseñar el firmware que sólo quemarlo) me llevó a una nueva aventura.
Mi pensamiento simple me llevó a sacar conclusiones equivocadas, basándome en premisas equivocadas, lo cual me llevó a hacer mi primer programa en microcontroladores para no terminar con un par de chips caros sin poder utilizar. La primera fue pensar que el código necesario para realizar la conexión USB utilizando V-USB era compacto. La segunda fue pensar que el leer el estado de un control de SNES era simple. La tercera y peor equivocación fue pensar que el código del ATTINY2313 me serviría para el ATTINY25.
En la página de Hobbyelektronik hay dos versiones del firmware para el ATTINY45, la primera con un valor de calibración del oscilador interno fijo y la segunda con calibración automática. En palabras simples, el ATTINYx5 puede funcionar a una alta frecuencia de operación utilizando su oscilador interno, lo que elimina la necesidad de utilizar un cristal oscilador como señal de reloj. Ahora bien, el oscilador no es muy preciso, por lo que puede tener desviaciones en su periodo de hasta el 5 por ciento. Dicha incertidumbre es inadmisible en un sistema que se conecta al puerto USB, donde los tiempos deben ser precisos, con una incertidumbre máxima del 1 por ciento. Es por ello que el oscilador debe calibrarse, colocando un valor en el registro OSCCAL (primer byte de la EEPROM del microcontrolador).
Ahora bien, la calibración del oscilador obedece a dos factores principales: el voltaje y el calor. Una variación en el voltaje de unos cuantos milivolts o una variación en la temperatura de operación puede variar la frecuencia del oscilador, por lo que el microcontrolador es incapaz de mantener la comunicación con el puerto USB. Si el firmware usa un valor de calibración fijo, dicho valor debe modificarse de forma manual en el firmware y volverse a grabar en el microcontrolador, en un proceso de prueba y error, hasta que se logre la comunicación entre el adaptador y el puerto USB. Cuando se emplea la calibración automática, el microcontrolador se sincroniza con el puerto USB en cada ciclo de RESET. La desventaja de la calibración automática es que si el adaptador comparte el hub USB con otros dispositivos, es muy probable que nunca pueda calibrarse.
Además, la rutina de calibración utiliza espacio en memoria muy valioso, ante todo cuando sólo se dispone de 2048 bytes. En primera instancia la opción ganadora es el firmware con calibración automática, sin embargo el firmware de Hobbyelektronik tiene dos problemas: el primero es que utiliza más de 2048 bytes y el segundo es que según su autor, no funciona.
En Instructables, un usuario llamado Andreq realizó unas optimizaciones que permitián utilizar un microcontrolador de 2kB para hacer el adaptador. Sin embargo el firmware de Andreq no contaba con la calibración automática. Con estos antecedentes, decidí poner manos a la obra con dos objetivos en mente: lograr optimizar el código lo suficiente como para entrar en un ATTINY25 y la segunda, implementar una función de calibración automática optimizada.
Mi pensamiento simple me llevó a sacar conclusiones equivocadas, basándome en premisas equivocadas, lo cual me llevó a hacer mi primer programa en microcontroladores para no terminar con un par de chips caros sin poder utilizar. La primera fue pensar que el código necesario para realizar la conexión USB utilizando V-USB era compacto. La segunda fue pensar que el leer el estado de un control de SNES era simple. La tercera y peor equivocación fue pensar que el código del ATTINY2313 me serviría para el ATTINY25.
En la página de Hobbyelektronik hay dos versiones del firmware para el ATTINY45, la primera con un valor de calibración del oscilador interno fijo y la segunda con calibración automática. En palabras simples, el ATTINYx5 puede funcionar a una alta frecuencia de operación utilizando su oscilador interno, lo que elimina la necesidad de utilizar un cristal oscilador como señal de reloj. Ahora bien, el oscilador no es muy preciso, por lo que puede tener desviaciones en su periodo de hasta el 5 por ciento. Dicha incertidumbre es inadmisible en un sistema que se conecta al puerto USB, donde los tiempos deben ser precisos, con una incertidumbre máxima del 1 por ciento. Es por ello que el oscilador debe calibrarse, colocando un valor en el registro OSCCAL (primer byte de la EEPROM del microcontrolador).
Ahora bien, la calibración del oscilador obedece a dos factores principales: el voltaje y el calor. Una variación en el voltaje de unos cuantos milivolts o una variación en la temperatura de operación puede variar la frecuencia del oscilador, por lo que el microcontrolador es incapaz de mantener la comunicación con el puerto USB. Si el firmware usa un valor de calibración fijo, dicho valor debe modificarse de forma manual en el firmware y volverse a grabar en el microcontrolador, en un proceso de prueba y error, hasta que se logre la comunicación entre el adaptador y el puerto USB. Cuando se emplea la calibración automática, el microcontrolador se sincroniza con el puerto USB en cada ciclo de RESET. La desventaja de la calibración automática es que si el adaptador comparte el hub USB con otros dispositivos, es muy probable que nunca pueda calibrarse.
Además, la rutina de calibración utiliza espacio en memoria muy valioso, ante todo cuando sólo se dispone de 2048 bytes. En primera instancia la opción ganadora es el firmware con calibración automática, sin embargo el firmware de Hobbyelektronik tiene dos problemas: el primero es que utiliza más de 2048 bytes y el segundo es que según su autor, no funciona.
En Instructables, un usuario llamado Andreq realizó unas optimizaciones que permitián utilizar un microcontrolador de 2kB para hacer el adaptador. Sin embargo el firmware de Andreq no contaba con la calibración automática. Con estos antecedentes, decidí poner manos a la obra con dos objetivos en mente: lograr optimizar el código lo suficiente como para entrar en un ATTINY25 y la segunda, implementar una función de calibración automática optimizada.
lunes, 4 de abril de 2011
Adaptador de control de SNES a USB (Here comes a new challenger!!!).
Con un prototipo funcional (en protoboard, pero al cabo funcional) decidí poner manos a la obra. Pero antes, se me ocurrió la "brillante" idea de investigar más a fondo sobre los adaptadores de controles de consolas al puerto USB, sobre todo porque revisando los números me percaté que estaba utilizando sólo un tercio de la capacidad en memoria del microcontrolador. Ante esta circunstancia me saltaron en la mente dos alternativas: la primera era darle una mayor compatibilidad al adaptador (agregar soporte para más controles) y la segunda era optimizar el adaptador (utilizar un microcontrolador más barato y con menor capacidad).
Como ejemplo de la primera alternativa encontré el proyecto de Retro Adapter de Paul Qureshi, en el cual se usa un microcontrolador de 16 kB de memoria para dar compatibilidad a un chorro de controles. El ejemplo de la segunda alternativa la encontré en el proyecto de Hobbyelektronik, donde con un microcontrolador de 4 kB sincronizado por software y con un microcontrolador de 2 kB sincronizado con cristal de cuarzo realizan el adaptador.
Debo admitirlo, soy un fanático de la optimización, así que el proyecto de Hobbyelektronik me pareció una mejor alternativa que el prototipo que ya había comenzado. Además, de forma completamente "misteriosa" los microcontroladores ATMEGA8 y los cristales de cuarzo de 12 MHz (los necesarios para sincronizar el microcontrolador con el puerto USB) subieron de precio como la espuma de un chesco agitado... Pero a diferencia de la espuma, los precios se han mantenido altos desde aquella fecha.
Así que decidí armar el adaptador que utilizaba el ATTINY2313. Cabe mencionar que si bien, el microcontrolador recomendado debe tener una frecuencia de operación de 20 MHz (terminación 20PU), es posible usar el de frecuencia de 10 MHz (10PU) y "overclockearlo" con el cristal de 12 MHz. Inclusive, el desarrollador original de la interfaz de los microcontroladores AVR a USB hizo sus primeros experimentos con un AT90S2313 (antecesor de los ATTINY2313) de 10 MHz.
Así que puse manos a la obra, compré un ATTINY2313-20PU (en uno de los locales del número 24 de la calle de República del Salvador), reutilizé todos los componentes del prototipo anterior, quemé el firmware en el microcontrolador y todo funcionó de maravilla.
Las pruebas fueron satisfactorias, el adaptador fue sumamente estable, sin lag o retrasos en los botones, barato y sobre todo, cumplió con mis expectativas de optimización. El circuito quedó muy padre, dentro de un bloque de plástico de 3x7 cm. Hice un cople adaptador del control de SNES a conector DB9. El conector DB9 se conectaba al bloque de plástico que contenía el circuito adaptador y éste se conectaba por otro cable al puerto USB.
Hasta aquí todo podría quedar en un final feliz... Sin embargo todo es perfectible, todo puede mejorar, y además AG trajo los ATTINY25 a un precio bastante competitivo, así que decidí poner manos a la obra... una vez más.
Como ejemplo de la primera alternativa encontré el proyecto de Retro Adapter de Paul Qureshi, en el cual se usa un microcontrolador de 16 kB de memoria para dar compatibilidad a un chorro de controles. El ejemplo de la segunda alternativa la encontré en el proyecto de Hobbyelektronik, donde con un microcontrolador de 4 kB sincronizado por software y con un microcontrolador de 2 kB sincronizado con cristal de cuarzo realizan el adaptador.
Debo admitirlo, soy un fanático de la optimización, así que el proyecto de Hobbyelektronik me pareció una mejor alternativa que el prototipo que ya había comenzado. Además, de forma completamente "misteriosa" los microcontroladores ATMEGA8 y los cristales de cuarzo de 12 MHz (los necesarios para sincronizar el microcontrolador con el puerto USB) subieron de precio como la espuma de un chesco agitado... Pero a diferencia de la espuma, los precios se han mantenido altos desde aquella fecha.
Así que decidí armar el adaptador que utilizaba el ATTINY2313. Cabe mencionar que si bien, el microcontrolador recomendado debe tener una frecuencia de operación de 20 MHz (terminación 20PU), es posible usar el de frecuencia de 10 MHz (10PU) y "overclockearlo" con el cristal de 12 MHz. Inclusive, el desarrollador original de la interfaz de los microcontroladores AVR a USB hizo sus primeros experimentos con un AT90S2313 (antecesor de los ATTINY2313) de 10 MHz.
Así que puse manos a la obra, compré un ATTINY2313-20PU (en uno de los locales del número 24 de la calle de República del Salvador), reutilizé todos los componentes del prototipo anterior, quemé el firmware en el microcontrolador y todo funcionó de maravilla.
Las pruebas fueron satisfactorias, el adaptador fue sumamente estable, sin lag o retrasos en los botones, barato y sobre todo, cumplió con mis expectativas de optimización. El circuito quedó muy padre, dentro de un bloque de plástico de 3x7 cm. Hice un cople adaptador del control de SNES a conector DB9. El conector DB9 se conectaba al bloque de plástico que contenía el circuito adaptador y éste se conectaba por otro cable al puerto USB.
 |
| Conector casero para controles de SNES. |
 |
| Chasis fabricado a partir de un "FacoBlock" (MegaBlock genérico X_x) |
 |
| Nótese la pulcritud y profesionalismo del acabado X_x. |
Hasta aquí todo podría quedar en un final feliz... Sin embargo todo es perfectible, todo puede mejorar, y además AG trajo los ATTINY25 a un precio bastante competitivo, así que decidí poner manos a la obra... una vez más.
 |
| Festival de cables n_n. |
Adaptador de control de SNES a USB (renacimiento).
Después del fracaso del capítulo anterior, hacer rabieta, desquitarme con el mundo, pellizcarle el trasero (de forma completamente accidental debo aclarar) a unas maids en una convención de cómics, meditar (es decir, escuchar rock n_n), jugar Bayonetta y terminar Super Metroid en el ZSNES usando el control del XBOX360 (en efecto, ya contaba con un control USB a mi disposición) me sentí lo suficientemente tranquilo para darme otra oportunidad (si, a veces me cuesta trabajo superar mis depresiones).
Esta vez compré un microcontrolador ATMEGA8-16PU (encapsulado DIP o de "cucaracha") a 40 pesos mexicanos (aun no subían de precio) y todos los componentes fueron de los "normales" (o thru-hole para los expertos). Monté el prototipo en una protoboard, grabé el microcontrolador, esperé un rato (tres segundos), conecté el prototipo a la PC y ahora si, Windows reconoció el dispositivo. Esto me levantó la moral como pocas veces en mi vida. Sin embargo surgieron nuevas dificultades, conectar los controles de SNES al dichoso adaptador y hacer una nueva placa de circuito impreso. Dispuesto a poner manos a la obra veo mi calendario y ¡¡¡Oh sorpresa!!! Al día siguiente entraba a clases en la facultad X_x.
Así el proyecto quedó en el tintero todo un semestre. Vinieron de nuevo las vacaciones de invierno de 2010, recibí el Año Nuevo con toda mi familia (Cami se agregó junto con Maika, Neela y Yuki), finjí mi muerte en las redes sociales (no hay lugar ahí para un antisocial como yo), jugué Sakura Wars ~So long my love en PS2 (el mejor juego de PS2 que hay hasta la fecha) y el proyecto del adaptador... bien gracias n_n!
Esta vez compré un microcontrolador ATMEGA8-16PU (encapsulado DIP o de "cucaracha") a 40 pesos mexicanos (aun no subían de precio) y todos los componentes fueron de los "normales" (o thru-hole para los expertos). Monté el prototipo en una protoboard, grabé el microcontrolador, esperé un rato (tres segundos), conecté el prototipo a la PC y ahora si, Windows reconoció el dispositivo. Esto me levantó la moral como pocas veces en mi vida. Sin embargo surgieron nuevas dificultades, conectar los controles de SNES al dichoso adaptador y hacer una nueva placa de circuito impreso. Dispuesto a poner manos a la obra veo mi calendario y ¡¡¡Oh sorpresa!!! Al día siguiente entraba a clases en la facultad X_x.
Así el proyecto quedó en el tintero todo un semestre. Vinieron de nuevo las vacaciones de invierno de 2010, recibí el Año Nuevo con toda mi familia (Cami se agregó junto con Maika, Neela y Yuki), finjí mi muerte en las redes sociales (no hay lugar ahí para un antisocial como yo), jugué Sakura Wars ~So long my love en PS2 (el mejor juego de PS2 que hay hasta la fecha) y el proyecto del adaptador... bien gracias n_n!
Adaptador de control de SNES a USB (primer brick)
En este capítulo de su melodrama predilecto "Un pseudo-nerd que cree que se rifa pero nel"...
Siguiendo al pie de la letra las instrucciones del sitio de Raphael, me dispuse a construir el mejor adaptador de controles de SNES a USB sobre la faz de la tierra. Mi adaptador iba a ser perfecto, es decir, iba a ser compacto, de diseño pulcro, acabados espectaculares, funcionalidad a toda prueba y lo mejor... la envidia de todos mis cuates, pues iba a ser el primer proyecto casero utilizando componentes SMD (componentes microscópicos que requieren de gran pericia para ser soldados) que muchos verían con sus propios ojos...
Después de dos días de diseño y construcción terminé el prototipo. Era hermoso pues tenía un excelente acabado y la placa de circuito impreso era negra (como en las tarjetas de video de gama alta). Llegó la hora de programar, conecté el programador a la PC, abrí el avrdude, le pasé los parámetros adecuados, presioné ENTER, esperé unos segundos (tres o cuatro por mucho) y todo parecía haber salido bien...
Conecté el adaptador al puerto USB de la PC mientras preparaba mi garganta para dar el mayor grito de logro de todas las vacaciones del verano de 2010... y salió en la barra de tareas de Windows XP un globito amarillo que decía (palabras más, palabras menos) lo siguiente: "El dispositivo USB no puede ser reconocido... bla... bla... lamer... jajajaja... bla... verifique las conexiones... bla..."
Acostumbrado a los fracasos del primer intento, desconecte el adaptador, lo conecté al programador para volver a grabar el firmware (o sea, seguramente ese era el error, mi diseño era perfecto...) y casi me "retoco el maquillaje" en mis pantalones cuando el avrdude se negó de forma autoritaria a reconocer el microcontrolador. No pude evitar sentirme deprimido, mi primer acercamiento con los microcontroladores y los circuitos SMD había sido un rotundo fracaso; dos días de diseño, un microcontrolador de 36 pesos mexicanos (aún estaban baratos), una placa de circuito impreso y algunos cuantos componentes más se fueron a la basura...
Siguiendo al pie de la letra las instrucciones del sitio de Raphael, me dispuse a construir el mejor adaptador de controles de SNES a USB sobre la faz de la tierra. Mi adaptador iba a ser perfecto, es decir, iba a ser compacto, de diseño pulcro, acabados espectaculares, funcionalidad a toda prueba y lo mejor... la envidia de todos mis cuates, pues iba a ser el primer proyecto casero utilizando componentes SMD (componentes microscópicos que requieren de gran pericia para ser soldados) que muchos verían con sus propios ojos...
Después de dos días de diseño y construcción terminé el prototipo. Era hermoso pues tenía un excelente acabado y la placa de circuito impreso era negra (como en las tarjetas de video de gama alta). Llegó la hora de programar, conecté el programador a la PC, abrí el avrdude, le pasé los parámetros adecuados, presioné ENTER, esperé unos segundos (tres o cuatro por mucho) y todo parecía haber salido bien...
Conecté el adaptador al puerto USB de la PC mientras preparaba mi garganta para dar el mayor grito de logro de todas las vacaciones del verano de 2010... y salió en la barra de tareas de Windows XP un globito amarillo que decía (palabras más, palabras menos) lo siguiente: "El dispositivo USB no puede ser reconocido... bla... bla... lamer... jajajaja... bla... verifique las conexiones... bla..."
Acostumbrado a los fracasos del primer intento, desconecte el adaptador, lo conecté al programador para volver a grabar el firmware (o sea, seguramente ese era el error, mi diseño era perfecto...) y casi me "retoco el maquillaje" en mis pantalones cuando el avrdude se negó de forma autoritaria a reconocer el microcontrolador. No pude evitar sentirme deprimido, mi primer acercamiento con los microcontroladores y los circuitos SMD había sido un rotundo fracaso; dos días de diseño, un microcontrolador de 36 pesos mexicanos (aún estaban baratos), una placa de circuito impreso y algunos cuantos componentes más se fueron a la basura...
domingo, 3 de abril de 2011
Adaptador de control de SNES a USB (Dash y ChaN al rescate).
Seguimos con el relato del adaptador de controles de SNES a USB.
Hace muchos meses (pero muchísimos meses), mi amigo Dash me cedió una laptop Toshiba T4700CT, una 486DX de 66 MHz con 8 MB de RAM, bajo la encomienda de que hiciera "cosas chéveres" con ella.
Esta computadora y Dash salvaron el día, ya que dicha computadora (cuyo nombre de cariño es la "Family") cuenta con puerto serial, puerto paralelo, sistemas operativos Windows 3.1 (basura) y DOS 6.2 (el mejor que existe). Así que sólo era cuestión de armar uno de esos programadores seriales o paralelos que hay en la red, comprar el microcontrolador (ATMEGA8 para el USBASP o ATTINY2313 para el USBtinyISP), hacer un circuito impreso, soldar unos cuantos componentes, conectar unos cuantos cables, cargar el firmware en el programa que transfiere los datos al chip y... ¡Un momento!... ¡¡¡Ni PonyProg ni AVRdude funcionan en entornos de 16-bits!!!... ¡¡¡Rayos!!!
Si bien, Dash ya había puesto su grano de arena (el hardware) faltaba el software... El cual vino de manos de ChaN. En la página de ChaN hay varios circuitos electrónicos y programas útiles, entre ellos un set de programadores para entornos de 16-bits.
Gracias a nuestros héroes (como viñeta de historieta de bajo presupuesto), pude hacer el USBtinyISP (primer gran logro de esta aventura) y proceder al próximo capítulo...
Hace muchos meses (pero muchísimos meses), mi amigo Dash me cedió una laptop Toshiba T4700CT, una 486DX de 66 MHz con 8 MB de RAM, bajo la encomienda de que hiciera "cosas chéveres" con ella.
 |
| La venerable Family. |
Esta computadora y Dash salvaron el día, ya que dicha computadora (cuyo nombre de cariño es la "Family") cuenta con puerto serial, puerto paralelo, sistemas operativos Windows 3.1 (basura) y DOS 6.2 (el mejor que existe). Así que sólo era cuestión de armar uno de esos programadores seriales o paralelos que hay en la red, comprar el microcontrolador (ATMEGA8 para el USBASP o ATTINY2313 para el USBtinyISP), hacer un circuito impreso, soldar unos cuantos componentes, conectar unos cuantos cables, cargar el firmware en el programa que transfiere los datos al chip y... ¡Un momento!... ¡¡¡Ni PonyProg ni AVRdude funcionan en entornos de 16-bits!!!... ¡¡¡Rayos!!!
Si bien, Dash ya había puesto su grano de arena (el hardware) faltaba el software... El cual vino de manos de ChaN. En la página de ChaN hay varios circuitos electrónicos y programas útiles, entre ellos un set de programadores para entornos de 16-bits.
 |
| El programador serial a ISP. |
Gracias a nuestros héroes (como viñeta de historieta de bajo presupuesto), pude hacer el USBtinyISP (primer gran logro de esta aventura) y proceder al próximo capítulo...
 |
| USBtiyISP en toda su gloria. |
Adaptador de control de SNES a USB (el principio).
Hace varios meses, vagando por sitios de videojugadores "retro" (melancólicos suena muy gay) encontré una serie de artículos donde se detallaba como conectar los controles de SNES a la PC.
Hace ya bastante tiempo (tiempos de vocacional y de vagancia en general) construí un adaptador de cinco controles del SNES al PC, utilizando los en aquel entonces famosos drivers y diagramas de DirectPad Pro. DirectPad Pro funcionaba de maravilla, pero al cabo del tiempo se hicieron presentes dos enormes detalles, el primero es que los drivers trabajaban con instrucciones de bajo nivel y dejaron de ser útiles en sistemas como Windows XP o NT, donde el acceso a recursos de hardware no se hacia de la misma forma que en los Windows 9x. El otro detalle es que la conexión de los controles se hacia por puerto paralelo. Resumiendo, DirectPad Pro servía de maravillas en las computadoras promedio de 2000 o 2001.
Al pasar del tiempo, la interfaz paralela y Windows9x prácticamente desaparecieron de las computadoras. Por ahí existía otro set de drivers de la interfaz DirectPad Pro que funcionaba en Windows XP (PSXPad), aunque nunca la probé en mi propia PC, gracias al amigo Max pude verla en acción y disfrutar de ella en los buenos tiempos de las retas de Queen of Hearts 99.
Actualmente la interfaz USB existe en prácticamente todas las computadoras, así que resulta conveniente construir cualquier adaptador o hardware en general apuntando a la arquitectura de dicho puerto, siempre y cuando la aplicación lo amerite. En la pagina de Raphael Assenat se detalla como hacer un adaptador de uno o hasta cuatro controles de SNES/NES por USB. Este diseño utiliza un microcontrolador ATMEGA8. Si bien, dicho microcontrolador era relativamente barato y fácil de encontrar a principios de 2010 en las tiendas de la calle de República del Salvador (Ciudad de México), a mediados de 2010 sufrió una alza de precio de mas del doble (en la actualidad cuesta 123 pesos mexicanos (11 USD) en cierta tienda llamada AG). Además se requería de un programador de microcontroladores compatible con los AVR de ATMEL.
La complicación más fuerte surgió cuando vi que los programadores más económicos se conectaban por el puerto serial o el puerto paralelo de la computadora (de los cuales, mi computadora no tiene ni uno) y los programadores USB son sensiblemente caros. Existen dos programadores USB de código y diagrama abiertos llamados USBASP y usbtinyisp. Ambos son excelente opciones, muy completos y confiables pero tienen un defecto en común... ambos utilizan un microcontrolador AVR que debe ser programado para que puedan funcionar.
Es decir, me encontré ante el clásico dilema del huevo y la gallina. Necesitaba un programador USB para programar un microcontrolador, pero dicho programador requería de la programación previa de un microcontrolador (irónicamente de la misma clase del que mi proyecto requería)...
Hace ya bastante tiempo (tiempos de vocacional y de vagancia en general) construí un adaptador de cinco controles del SNES al PC, utilizando los en aquel entonces famosos drivers y diagramas de DirectPad Pro. DirectPad Pro funcionaba de maravilla, pero al cabo del tiempo se hicieron presentes dos enormes detalles, el primero es que los drivers trabajaban con instrucciones de bajo nivel y dejaron de ser útiles en sistemas como Windows XP o NT, donde el acceso a recursos de hardware no se hacia de la misma forma que en los Windows 9x. El otro detalle es que la conexión de los controles se hacia por puerto paralelo. Resumiendo, DirectPad Pro servía de maravillas en las computadoras promedio de 2000 o 2001.
Al pasar del tiempo, la interfaz paralela y Windows9x prácticamente desaparecieron de las computadoras. Por ahí existía otro set de drivers de la interfaz DirectPad Pro que funcionaba en Windows XP (PSXPad), aunque nunca la probé en mi propia PC, gracias al amigo Max pude verla en acción y disfrutar de ella en los buenos tiempos de las retas de Queen of Hearts 99.
Actualmente la interfaz USB existe en prácticamente todas las computadoras, así que resulta conveniente construir cualquier adaptador o hardware en general apuntando a la arquitectura de dicho puerto, siempre y cuando la aplicación lo amerite. En la pagina de Raphael Assenat se detalla como hacer un adaptador de uno o hasta cuatro controles de SNES/NES por USB. Este diseño utiliza un microcontrolador ATMEGA8. Si bien, dicho microcontrolador era relativamente barato y fácil de encontrar a principios de 2010 en las tiendas de la calle de República del Salvador (Ciudad de México), a mediados de 2010 sufrió una alza de precio de mas del doble (en la actualidad cuesta 123 pesos mexicanos (11 USD) en cierta tienda llamada AG). Además se requería de un programador de microcontroladores compatible con los AVR de ATMEL.
La complicación más fuerte surgió cuando vi que los programadores más económicos se conectaban por el puerto serial o el puerto paralelo de la computadora (de los cuales, mi computadora no tiene ni uno) y los programadores USB son sensiblemente caros. Existen dos programadores USB de código y diagrama abiertos llamados USBASP y usbtinyisp. Ambos son excelente opciones, muy completos y confiables pero tienen un defecto en común... ambos utilizan un microcontrolador AVR que debe ser programado para que puedan funcionar.
Es decir, me encontré ante el clásico dilema del huevo y la gallina. Necesitaba un programador USB para programar un microcontrolador, pero dicho programador requería de la programación previa de un microcontrolador (irónicamente de la misma clase del que mi proyecto requería)...
Suscribirse a:
Entradas (Atom)
¡Feliz 2021! El retorno del debraye pandémico (Edición "Rompemuros").
Hola, ¿Cómo han estado? Espero que estén con bien, con buena salud y con muchas ganas de aburrirse una vez más con una ronda de debrayes. Es...
-
Hola que tal, ¿Cómo están? Espero que se encuentren bien, sobreviviendo a la pandemia y a la nueva normalidad. Por mi parte las cosas han id... -
Hola ¿Que tal? En esta entrada no estoy colocando descargas (buuu) ni nada. Simplemente estoy colocando los cheats que encontré para el jueg...
-
Hola, ¿Cómo están? Como siempre, espero que estén bien. Por fin he podido hacer un poco de espacio en la vida real para dedicarle un poco ...