SimusPlayer y el regreso a un antiguo proyecto

Hace una buen tiempo he estado viendo videos de Phils Computer Lab en donde muestra distintas tarjetas de sonido antiguas, comparando como suenan los archivos MIDI en cada una de ellas, y además de esos videos ha hecho algunos experimentos interesantes como simular un módulo MIDI externo usando un tablet conectado al PC que corre los juegos. En todos sus experimentos existe un factor común, que es un reproductor MIDI para Windows que tiene una interfaz de usuario muy funcional y al mismo tiempo muy atractiva para mí, el SoundFont MIDI player.

Todo lo que viene a continuación comenzó con la pregunta «y habrá algo así para Linux«? Me puse a buscar y encontré un montón de proyectos similares abandonados y también otro gran grupo de poderosas herramientas MIDI pero más orientadas a la producción musical, por ejemplo instrumentos virtuales o secuenciadores, pero yo quería simplemente un reproductor MIDI para Linux de escritorio que tuviera un aspecto similar a SoundFont MIDI player, no tan completo como éste, pero sí con algunas características claves como visualización de las pistas, notas, listas de reproducción, selección de dispositivo y patches.

A medida que seguí dándole vueltas al tema – en la ducha como muchos saben – la idea comenzó a convertirse en algo que va mucho más allá de un MIDI Player para Linux. Ya que vamos a hacer un reproductor de música, por qué tendría que ser sólo MIDI? Si bien sobran maneras de escuchar música en formato audio «normal» como Spotify, iTunes y otros, hay una gran cantidad de material interesante que se encuentra en otros formatos, como los formatos usados por los ModTrackers (MOD, S3M, XM, etc), o los formatos para música de consolas y computadores (SID, Pokey, VGM, etc).

Vaya, que hay todo un universo más allá de la música distribuida en forma comercial.

El enfoque es similar a lo que hace RetroArch con los emuladores, el motor y el frontend es uno solo, pero lo que cambia son los reproductores, en este caso de música. En realidad, el concepto no es tan nuevo, ya lo hacía Winamp a través de sus «input plugins».

Al soportar más formatos también se puede pensar en un display diferente para cada uno de ellos, quizás no específicamente por formato, pero si por el tipo de información disponible. Por ejemplo en música de trackers hay acceso a la forma de onda, y eso se podría desplegar cuando está disponible como se puede ver en la imagen de arriba.

El MIDI Player ya no es solamente un reproductor MIDI, sino que también es un reproductor de múltiples formatos de música digital, y pese a que es algo más complejo de implementar, desde el punto de vista del usuario es algo más simple de usar porque oculta las complejidades de los distintos formatos como si fueran uno solo. El player se llama SimusPlayer o (Simple Music Player), es de código abierto y ya se encuentra en github en su fase inicial.

Si expandimos más el modelo, también podemos agregar skins, procesadores de audio y un largo etc, pero vamos con calma que hay otro aspecto interesante en este proyecto.

MusicTrans y RetroX para sistemas de escritorio

Con ese título podrían pensar que cambié radicalmente de tema, pero como verán está más relacionado de lo que pueda parecer. Cuando hice MusicTrans para Android y lo comencé a usar para mi práctica de guitarra, vi que tener una versión para escritorio (Linux/Mac/Windows) sería bastante conveniente, y como la parte principal del código estaba hecha en C y el resto era Java para Android, ya tenía al menos algo avanzado. Lo que necesitaba hacer era cambiar la parte específica de Android por algún equivalente que funcionara en los sistemas de escritorio.

Lo que hice en esa ocasión fue implementar un «mini Android» que me permitió reutilizar gran parte del código de MusicTrans para Android, y en menos de un mes la versión de MusicTrans para Escritorio ya estaba publicada, terminó siendo prácticamente igual a la de Android en cuanto a aspecto y funcionalidad, y me abrió un mercado no despreciable de nuevos usuarios amantes de MusicTrans que también lo querían en sus escritorios.

Esto tampoco era algo nuevo, de hecho resolver el problema de soportar 3 de sistemas de escritorio diferentes en forma casi nativa ya estaba resuelto por SWT del proyecto Eclipse, y es lo que usé como base para hacer este mini-Android, es una idea que ya andaba rondando hace varios años atrás cuando daba mis primeros pasos en Linux, y que finalmente pude poner en práctica y disfrutar de sus resultados.

Vi que contar con un framework que me permitiera crear aplicaciones casi nativas para Android y sistemas de escritorio usando casi el mismo código no sólo me da un gran espacio de libertad para publicar aplicaciones, sino que incluso me permite rápidamente crear aplicaciones para escritorio con las mismas habilidades que uso normalmente para Android (Java y C).

Es así como el año 2016 comencé a crear una biblioteca similar a la que usé en MusicTrans pero esta vez orientada a cualquier tipo de aplicaciones y bajo la modalidad de código abierto. Bajo el nombre de FTS lo publiqué en GitHub y senté las bases de lo que sería un gran framework para mí, pero por motivos que ya no logro recordar el proyecto quedo congelado en el tiempo y sólo alcancé a hacer una aplicación de prueba que abre una ventana y nada más.

FTS es agnóstico respecto a el mecanismo de despliegue, FTS sabe qué es un cuadro de texto (TextBox) pero no sabe cómo se dibuja, sabe lo que significa que un objeto gráfico se dibuje al lado de otro, pero no sabe cómo traducir eso en la pantalla. Esto nuevamente no es nuevo, pero es una idea muy flexible: Existe un «driver» para FTS que es el que sabe cómo traducir estas intenciones en algo concreto. En el 2016 sólo hice pruebas con un solo driver, y es un driver que utiliza SWT para dibujar en pantalla, que es lo que tenía a mano en su momento y me sirvió para probar los conceptos fundamentales. El problema es que para Android no puedo usar SWT, y por ahora ese driver no continuará en desarrollo, por lo que tuve que buscar un driver que fuera común denominador entre Android y los sistemas de escritorio, y ese driver es basado en OpenGL ES.

Nuevamente, no es primera vez que planteaba algo similar. Cuando estuve haciendo RetroX para que corriera en forma nativa en Raspberry Pi sin utilizar X.org sino que dibujando directo en el framebuffer, hice un framework llamado SGL (Simple Graphics Library) que esta basado en OpenGL y que me permitió desarrollar en mi escritorio Linux con X.org y ejecutar en Raspberry Pi via framebuffer. SGL fue específico para RetroX y quedó congelado una vez que abandoné la versión de RetroX para Linux/Raspberry Pi, para enfocarme sólo en Android.

Finalmente, todo este código converge y como muchas veces he dicho, no hay que tener miedo de escribir código ni de «perderlo» porque siempre de alguna u otra forma ese aprendizaje o incluso el mismo código servirá. Es así como por ejemplo las mejoras que he hecho a la versión de RetroArch que incluye RetroX usan los conocimientos que adquirí desarrollando SGL, y ese mismo conocimiento ahora se integra a FTS.

Entonces, para resumir, FTS (2016) ha sido descongelado y usará un driver basado en OpenGL ES rescatando parte del código de SGL (2014), y será la base de RetroX para sistemas de escritorio (2020)

Y qué tiene que ver todo esto con el SimusPlayer? Pues SimusPlayer será el conejillo de indias que me permitirá poner a prueba FTS con algo mucho más pequeño y menos riesgoso que hacerlo con RetroX, y de paso me permitirá hacer que el SimusPlayer para Linux también pueda correr en Mac, Windows, Android y .. Android TV!

Y aquí la cosa se pone wena wena.

Más que un simple reproductor de música

Bajo la premisa de hacer un reproductor simple, al agregar Android TV algo que es tan natural en sistemas de escritorio como lo es abrir un archivo, se puede volver muy complicado para un usuario en una aplicación que corre en un televisor o incluso en un móvil. Esto que parece una dificultad es en realidad una oportunidad: Ya que los archivos de música en estos formatos son pequeños, y existen grandes bibliotecas con miles de archivos ya clasificados, por qué no hacer que el mismo reproductor permita buscar y descargar estas canciones!! Por enésima vez, la idea no es nueva y esta aplicación sería como «un Spotify para MIDI/XM/S3M/MOD, etc». Como se trata de una aplicación muy de nicho y los archivos son bastante pequeños, el costo de transferencia de datos desde un repositorio propio no debería ser un problema, para la infraestructura que ya tengo andando con RetroX sería sólo un costo marginal.

Como en otros proyectos, inicialmente esto sería sólo para mi uso personal, la diversión está en construirlo y luego disfrutar lo construido, pero aún podemos ir más allá!

SimusPlayer module

Hace unos días conversaba con mi amigo Cristian Astudillo (Atariado) por la compra/venta de los parlantes que él fabrica como AsDub y en el conjunto me ofreció un amplificador Pioneer que es parte de su equipo modular. El módulo es bien bonito y me quedé pensando en cómo extenderlo un poco para que no se viera tan solo, y me acordé que tenía un módulo Sony reproductor de CD por ahí sin usar, sería la compañía perfecta.

Pero luego pensé, y…. por qué no convertir SimusPlayer en un módulo de más? Si la aplicación ya está orientada a ser usada en un Android TV, todas las características de «uso doméstico» la dejan lista para ser integrada en un módulo, o sea, convertir SimusPlayer en un hardware modular.

Otra vez, esto no es nuevo! Roland y otros fabricantes construyeron módulos MIDI que permiten reproducir sonidos y música en formato MIDI de forma independeinte, la idea sería similar pero cubriendo mucho más que sólo MIDI. Roland es una gran inspiración en cuanto a diseño y en cuanto a cómo debería funcionar un equipo de estas características, se podría hacer con una pantalla LED/LCD, una Raspberry Pi, y mucha ayuda de otros amigos expertos en hardware como Atariado y Gastón Centeno (Tongas).

En mi imaginación, veo un display themeable, idealmente un boot corto para que el equipo quede operativo en pocos segundos, control remoto via bluetooth y también control remoto via una simple app para Android. Las posibilidades de entretención construyendo este proyecto son infinitas, y quién sabe, quizás se podría convertir en un aparato interesante para otros que disfrutan de este tipo de música.

Finalmente, esta idea tampoco es nueva! A fines de los años ’90 con mi amigo Max Celedón queríamos hacer un proyecto de este tipo y se llamaba Multi-Audio, la idea era tener un equipo independiente que pudiera reproducir archivos MP3, MOD, MIDI, etc. En ese tiempo al menos MP3 necesitaba un equipo poderoso y la única opción era usar un PC, jamás había usado Linux y la única opción factible era modificar la BIOS para simplificar el proceso de boot y hacer unos simples drivers de DOS para manejar la tarjeta de sonido. Al final abandonamos el proyecto porque sospechábamos que en cualquier momento algún fabricante grande lo haría, cosa que jamás ocurrió, sólo agregaron MP3 muchos años después y los otros formatos de música pasaron al olvido.

Los conceptos de Multi-Audio después fueron aplicados a las primeras aplicaciones para televisión que hice, en donde se combinaban múltiples formato de video en vez de sólo audio, y posteriormente el mismo concepto se aplicó para Multi-Emuladores, lo que hoy se conoce como RetroX. Hacer este nuevo proyecto es darse la vuelta completa a los inicios de todo, con la ventaja de que ahora la tecnología disponible lo permite hacer. Tecnología al alcance de todos como es Linux, Raspberry Pi, servicios en la nube, impresoras 3D, componentes electrónicos económicos, cortadoras laser, etc, permiten jugar a ser inventor y disfrutar del proceso. Vamos a ver como resulta todo esto!

Cuando el desarrollo de software se complica

Esta historia aun no ha terminado pero vengo acá sólo para desahogarme. El desarrollo de software a veces puede ser muy cabrón, sobre todo cuando hay que interactuar con componentes sobre los que no se tiene control, y protocolos diseñados por enajenados mentales.

RetroX soporta conectarse a unidades de red (Windows/NAS) para cargar juegos, el protocolo (SMB/CIFS) es muy antiguo y tiene todo tipo de problemas, sin embargo hay bibliotecas como jCIFS que ayudan a implementarlo en Android y aplicaciones Java.

Un usuario reportó un problema de conexión hacia su Shield y efectivamente RetroX arroja error porque el servidor retorna un valor vacío en vez de la lista de elementos compartidos. El error lo reporta la biblioteca y es el típico Null Pointer Exception cuando trata de obtener una lista de recursos compartidos. Parece un easy fix.

Para no alargar la historia, acá un resumen de lo que ha significado diagnosticar el problema, encontrar la causa y aún así, no tener la solución:

  1. Comprobar que el uso de jCIFS esté correcto
  2. Revisar si es o no un bug conocido y corregido en jCIFS
  3. Descartar un problema de seguridad
  4. Descartar un problema de protocolo
  5. Revisar el código y encontrar el punto exacto de la caída para ver si es simple de corregir. Y no lo es.
  6. Asumir que fue corregido y actualizar la biblioteca,pero
    1. Hay 3 forks divergentes y se debe escoger uno
    2. Hay que revisar la historia de cada uno y por qué existe
    3. Compruebo dolorosamente que no todos funcionarán con Android
  7. Escogido uno, hacer lo necesario para que se pueda usar en Android
  8. Una vez actualizado jCIFS, aparece problema de protocolo. Ahora soportan SMB2 pero la Shield no.
  9. Solucionado el problema de protocolo, volvemos al error original!!! Viene un valor vacío desde la Shield.
  10. Consigo un Windows para ver si es un problema exclusivo de la Shield y efectivamente, Windows si se conecta (*)
  11. Usando Samba compruebo que sí me puedo conectar a la Shield y a Windows, mientras que jCIFS solo a Windows.

Todo apunta a un problema de cliente, y como Samba se conecta, ahora es cosa de comparar jhacer pruebas con jCIFS y con Samba para ver cuál es la diferencia entre ambos clientes.

  1. Usando Wireshark reviso toda la comunicación y sólo aparece una diferencia. El server dice File Not Found
  2. Me enfoco en identificar problemas relacionados con nombres. Pero todos los nombres son iguales en ambos casos
  3. Verifico las peticiones antes del error via Wireshark y ambas son idénticas también!!!!!
  4. Desde la Shield no puedo ver nada, excepto que el server instalado ahí dice «Alfresco»
  5. No hay rastros de un server SMB publicado por Alfresco hasta que doy con un comunicado de prensa y se llama JLAN… con un link al código fuente
  6. Instalo el servidor de Alfresco que está con código código fuente y lo puedo intervenir. Esto es mejor que probar con la Shield al menos!
  7. El error se replica! Comienzo a buscar reportes de este problema
  8. Sólo encuentro preguntas sin respuestas o links rotos.
  9. Mostrando la interpretación del protocolo desde Alfresco logro encontrar una diferencia!!! Veo que jCIFS envía un «0x10000» cuando debe enviar «1»
  10. Modifico Alfresco para que siempre crea que viene el valor como «1» y ahora funciona!!!
  11. Me voy a dormir pensando en que solo basta con corregir jCIFS para que envíe el valor correcto.
  12. Dia siguiente. En ninguna parte jCIFS envía ese valor, pero sí envía un «1». Al parecer sería un problema de interpretación de Alfresco o de codificación de jCIFS
  13. Modificando Alfresco encuentro que lee la secuencia «00 00 01 00» en vez de leer «01 00 00 00». Hay dos bytes corridos
  14. Determino dos causas probables:
    1. El string que viene antes jCIFS lo envía con «00 00» al final y Alfresco no espera eso
    2. El byte alignment entre Alfresco y jCIFS no es el mismo y por eso se corre 2 bytes
  15. Busco que dice la especificación de SMB y ohhh my god
    1. No hay una especificación de SMB sino múltiples
    2. La especificación está basada en protocolos heredados (NetBios y hasta X.)
    3. Leer leyes es más fácil que entender esta especificación!! Hay referencias cruzadas para todos lados y no llegas a ninguna parte que realmente sirva para este caso.
    4. Me encuentro con joyas del tipo : «Los strings a veces van con 00 00 al final, y a veces NO»
    5. Y otras como, a veces el alignment es relativo al paquete y otras veces relativo al mensaje
  16. Busco otras referencias / análisis de SMB y encuentro
    1. Un libro sobre CIFS muy bueno pero que no cubre esa parte
    2. Análisis de SMB pero de v2. Gra-cias.
  17. No importa, el código es la primera referencia. Sabemos que Samba lo hace bien, revisemos
  18. Horror! El código de Samba…
    1. Son 3082 archivos en C
    2. Ninguno hace referencia a la llamada que busco, tampoco se ve la parte de codificación del mensaje tras varios minutos de búsqueda
    3. Tiene directorios llamados source2, source3 en donde el contenido está duplicado, y dentro de él duplicado nuevamente. También aparecen carpetas como rpc_client y rpcclient. Cual es cual? No se sabe.  Para buscar es un infierno
  19. Probemos a fuerza bruta entonces y vamos descartando. Compruebo que el string tanto en Alfresco, Samba y jCIFS termina con «00 00» y por lo tanto es un problema de alignment y no de strings terminados en 0.
  20. En Alfresco el alignment es de 4 bytes. Hago el cambio en jCIFS y… tampoco funciona
  21. El problema del alignment es que depende del nombre del host, entonces a veces puede funcionar y a veces no, dependiendo del largo de ese nombre. * Es una posible explicación a por qué para jCIFS o Alfresco este problema ha sido reportado pero no lo han logrado replicar, y por qué algunos usuarios si se pueden conectar a la Shield desde RetroX y otros no.
  22. Reviso el código del alignment en jCIFS y veo que es relativo al mensaje, pero para Alfresco es relativo al contenedor del mensaje. Cuando Alfresco hace alignment al valor, jCIFS no, y vice versa.
  23. Podría pensar que Alfresco tiene el error, pero si Samba logra conectarse entonces se puede codificar el mensaje en forma correcta.
  24. Podría modificar Alfresco, pero ese código corre dentro de la Shield y no es modificable ahí. Puedo implementar quizás un workaround desde el punto de vista del cliente pero…
  25. Si corrijo jCIFS se rompe todo el resto de sus llamadas, porque asume alignment relativo la mensaje, sin embargo esa versión funcionaría con la Shield….

Mientras tanto, los usuarios me siguen preguntando si podrán conectarse a la Shield via SMB, ya que desde otras aplicaciones si pueden… claro, son aplicaciones cuyo único propósito es conectarse a la Shield y probablemente están usando Samba en forma nativa, un terreno al que no me gustaría entrar para algo tan simple. Mejor hago un servidor propio!

Como comentario final, es impresionante el nivel de complejidad de protocolos «corporativos antiguos» como SMB para algo que es relativamente simple. Dentro del protocolo metieron RPC, Named Pipes y lo que tuvieran a mano, pensar que con simple HTTP se puede hacer lo mismo y más.


Actualización 1: Dejaré de luchar un rato, reporté el bug a ver si hay alguna ayuda: https://github.com/AgNO3/jcifs-ng/issues/211

Actualización 2: Logré un workaround que debería servir por mientras (20 de Marzo)

La continuación de esta historia es más o menos así: Ya abandonado el branch de SMB para RetroX y dando por congelado el tema, aparece en mi ToDo list una tarea que alguna vez anoté y que dice «Sources: SMB2 via SMBJ». Aha!! Otra hay otra implementación para revisar, vamos a ver!

Hago las pruebas respectivas e implementa sólo SMB2 y SMB3, que no me sirve porque la compatibilidad que necesito es con SMB1. Reviso en mayor profundidad y veo que el protocolo es totalmente diferente así que nada más que hacer. Pero… mientras buscaba la versión compilada de SMBJ en el repositorio de Maven aparece un proyecto relacionado llamado SMBJ-RPC, y se trata justamente de la parte del protocolo que está fallando en SMB1. Paso a enumerar para facilitar el relato:

  • Aprendo que el request que lista los recursos compartidos es parte de un servicio llamado MS-SRVS (y no SMB / LanMan como uno pensaría)
  • DCE-RPC que es la parte que estuve revisando en jCIFS es quien permite invocar los servicios de MS-SRVS. En DCE-RPC se define el alignment de los datos y esa parte la documentan los amigos de SMBJ-RPC.
  • Y para mayor goce SMBJ-RPC tiene el código fuente para NetShareEnumRequest, la llamada que me está dando problemas!
  • En el código además está el link hacia la especificacón de Microsoft para MS-SRVS.
  • La spec dice lo siguiente señoras y señores: ServerName: If this parameter is NULL, the local computer is used.  O sea, que si paso un valor nulo en vez del nombre del servidor, se elimina la dependencia del alignment!!!
  • Reviso el código de SMBJ-RPC y justamente, pasan un valor nulo antes del InfoLevel
// <NDR: pointer[struct]> [in, string, unique] SRVSVC_HANDLE ServerName,
packetOut.writeNull();

// [in, out] LPSHARE_ENUM_STRUCT InfoStruct
// <NDR: unsigned long> DWORD Level
// Alignment: 4 - Already aligned
packetOut.writeInt(getShareEnumLevel().getInfoLevel());
  • Ahí además se ve claramente que InfoLevel debe ir alineado, por lo que jlan está correcto, el que falla en esa parte es jCIFS
  • Problem is: Incluso si aplico el alineado en jCIFS lo calcula mal dependiendo del nombre del servidor pero… el nombre puede ir nulo o vacio!
  • Pruebo con NULL y jCIFS se queda esperando respuesta de jlan, tampoco le gustó. Pero qué pasa si pruebo con string vacío?
 if ( this.servername != null ) {
    // _dst.enc_ndr_string(this.servername);
    _dst.enc_ndr_string("");
 }

FUNCIONA!!!!

Este cambio hace que el alignment ya no dependa del nombre del servidor porque tanto el pointer como el string vacío dejan el valor alineado de InfoLevel a 4 bytes.

Ahora, todavía me queda la duda de quién está calculando mal el alignment, si jlan o jCIFS, pero eso lo dejo en manos de ellos en el bug report de jCIFS.

Por otro lado jlan/alfresco dice:

Anyway, there is really no point working with that library any more, since Alfresco does not support its use in a standalone capacity (standalone library hasn’t had a release since ca. 2009) and will remove the support of CIFS / SMB based shared drives in one of the upcoming versions since Microsoft / WIndows no longer supports the old CIFS / SMB 1.0 dialect provided by JLAN.

Pero el problema es que Nvidia Shield está usando esa biblioteca. La cambiarán?

Actualización 3: Finalmente encontraron el bug en jCIFS, siempre estuvo ahí pero se desconocía la causa. Ya lo corrigieron y al menos en mis pruebas funciona bien. La vida puede continuar!

Turns out the SMB_COM_TRANSACTION padding algorithm has been wrong all the time (padding two 2 bytes among other things). So this was caused by missing padding before the NetShareEnum structure.

 

El motor de una micro-revolución: MOS 6502

A principios de los ’70 un grupo de ingenieros de Motorola estaba convencido de que era posible obtener un microprocesador barato si se planteaba un diseño simple y un proceso de fabricación mejorado respecto a los estándares de la época. Sin contar con el apoyo de la compañía, este grupo crearía una de las familias de chips que sería el catalizador de la revolución de la computación hogareña, se trata del 6502 y sus sucesores, principal motor de las primeras máquinas de Atari y Apple, entre otros.

Chuck Peddle era uno de los ingenieros líderes en el desarrollo del procesador 6800 de Motorola, en sus reuniones con importantes clientes industriales, se dio cuenta de que la tecnología era apreciada, pero demasiado cara para ser usada en forma masiva. En conversaciones con sus clientes llegó a la conclusión de que el costo del procesador tenía que bajar de los USD$300 que costaba el 6800 a sólo USD$25 de la época, conclusión que no alegró para nada a los directivos de Motorola que no tenían ninguna motivación para buscar reducir el precio de una tecnología que ya tenía buenas ventas.

Para Chuck y otros ingenieros, se trataba de un interesante desafío técnico y sin contar con el apoyo de Motorola comenzaron a trabajar en los cambios necesarios para mejorar su procesador. Por una parte el equipo estaba descontento por el escaso apoyo de Motorola, y por otra parte la compañía estaba molesta por la porfía de Chuck y su equipo, finalmente la gota que rebalsó el vaso fue la petición formal de Motorola para detener el proyecto, lo que hizo que Chuck y su equipo decidieran abandonar la compañía, para seguir trabajando en su microprocesador por su propia cuenta.

El grupo se integró a una compañía de bajo perfil llamada MOS, en donde llegaron a un acuerdo para participar en las ganancias que podrían obtener con el nuevo microprocesador, un acuerdo que desde el punto de vista de MOS era conveniente por la baja rentabilidad que significaba en ese tiempo la producción de estos chips. Este acuerdo, junto a la renuncia en masa de Motorola era una demostración de la confianza que tenía el equipo de ingenieros en el producto que estaban desarrollando.

El 6501 demuestra a Motorola que estaban equivocados

MOS 6501

El primer procesador de la serie 6500 fue el 6501. Un hecho inédito que rodeó el desarrollo de este chip fue que Chuck lo diseñó completamente a mano y funcionó en el primer intento, cuando lo normal en esos años era pasar por un proceso de más de 10 intentos fallidos. Este procesador fue bastante escaso ya que no se hizo con el fin de ser vendido, sino como una forma de demostrar a Motorola lo equivocados que estaban, y que sí se podía construir un microprocesador útil y barato.

Uno de los factores que influyeron en la reducción de los costos de producción fue una innovación de estos ingenieros respecto al proceso de fabricación. En esos tiempos, la tasa de fallas en la producción era de un 70%, es decir, sólo 7 de cada diez procesadores fabricados iban directo a la basura. Esto ocurría principalmente debido a que el proceso consistía en crear un gran molde del procesador e ir aplicando reducciones hasta llegar al tamaño real, en estas reducciones siempre ocurrían errores y los ingenieros en MOS encontraron una forma de aplicar correcciones al molde en cada reducción, logrando con este cambio una tasa de éxito de un 70%, es decir, 7 de cada 10 procesadores resultaban perfectos.

El 6501 era totalmente compatible con las placas del Motorola 6800 y podía ser usado como un reemplazo directo a nivel de hardware, lo que motivó una demanda de Motorola por supuesta violación de patentes de sus ex-ingenieros. Supuesta porque en realidad lo que estaba en juego era la propiedad intelectual, ya que se estaba aplicando el conocimiento de tecnologías que en realidad no estaban patentadas. Aún así, se llegó a un acuerdo con Motorola y se pagó una suma de unos USD$200.000 para detener el pleito.

MOS presenta el 6502 desafiando a Intel y Motorola

Jobs y Wozniak en 1976

El problema con Motorola provocó la creación del 6502, se trataba de un 6501 pero incompatible con el hardware diseñado para el Motorola 6800. El 6502 debutó en WestCon 1975 al precio exacto de USD$25 que se habían propuesto. Al principio los asistentes pensaron que se trataba de algún tipo de estafa, ya que no se concebía crear un procesador tan económico, pero en el mismo día Motorola e Intel bajaron el precio de sus procesadores 6800 y 8080 de USD$179 a sólo USD$69, validando al 6502 que se vendió por cientos.

En esos años, Commodore que estaba en el negocio de las calculadoras, estaba pasando por aprietos económicos ya que el negocio iba en bajada y la competencia era cada vez más fuerte. Como una estrategia para cambiar el rumbo del negocio, compraron a MOS que también estaba pasando por aprietos pero que contaba con la tecnología que ellos necesitaban.

Para Chuck, el negocio de los microprocesadores estaba orientado al mundo industrial, sin embargo mientras visitaba a distintas empresas para tratar de vender el 6502 le dijeron que un par de chicos estaban tratando de usar su procesador para construir un computador personal. El hecho le pareció simpático y accedió a ir a ayudarles a su garage, se trataba nada más y nada menos que de Steve Jobs y Steve Wozniak quienes trabajaban en su primer computador Apple. Chuck pensaba en masificar el 6502 en las industrias y para nada sospechaba que el gran mercado estaba en los computadores personales. Ni en un millón de años! Según sus propias palabras.

El legado del 6502

Atari 800XL

El 6502 es un procesador de 8 bits, esto quiere decir que todas sus operaciones internas maneja números entre 0 y 255, por otra parte posee un bus de direcciones de 16 bits que le permite acceder hasta 64KB de memoria. El 6502 normalmente operaba con un reloj entre 1 y 2 Mhz pero dada una misma frecuencia de reloj era capaz de funcionar mucho más rápido que el 6800 de Motorola, gracias a su astuto diseño que reducía el número de ciclos de reloj necesarios para ejecutar una instrucción. Como pueden ver, ya desde esos años la frecuencia de reloj del procesador se podía prestar para malentendidos.

Entre los computadores que se construyeron en torno al 6502 encontramos el Commodore PET, VIC-20, Apple I y II, BBC Micro y toda la linea de computadores Atari de 8 bits (XL, XE, 400, 800, etc), incluso en otro tipo de dispositivos como la unidad de disco 1541 de Commodore.

En la pionera consola Atari 2600 se utilizó una versión económica del 6502 conocida como 6507, versión que contaba con menos pines y sólo podía acceder a 8KB de memoria. El Commodore 64 también usó un 6502 modificado, se trataba del 6510 en donde se agregó funcionalidades simples que normalmente se implementaban con circuitería adicional.

Sin duda una de las variantes más interesantes del 6502 la encontramos en la consola Nintendo Entertainment System (NES), en donde se usaba un 6502 en que funcionalidad no utilizada en la programación de videojuegos fue reemplazada por generación de sonido, manejo de joysticks y sprites, convirtiendo al procesador en un conveniente sistema integrado en un chip (system on a chip).

El 6502 fue un microprocesador que continuó su legado en el mundo de los 16 bits. Una versión de 16 bit conocida como 65C816 es el corazón de la consola Super Nintendo. También encontramos una versión especial del 6502 con modificaciones orientadas a videojuegos en la consola TurboGrafx-16/PC-Engine, en donde se podía cambiar la velocidad del procesador hasta llevarlo a unos 7Mhz.

Como se puede ver, el 6502 estuvo presente en al menos tres frentes de los inicios de la computación hogareña, desde el lado hi-end en Apple hasta computadores menos ambiciosos pero tremendamente exitosos como los de Commodore y Atari. Lo que impresiona aún mas es ver que el mismo procesador que iniciaba la computación personal fue el que inició el mercado de los videojuegos hogareños con el Atari 2600, y tras la debacle de Atari en 1983 que casi termina con la industria de los videojuegos, vuelve en gloria y majestad en el NES de Nintendo para iniciar un camino sin retorno en este mercado.

Links:
MOS Technology 6502 (Wikipedia)
The rise of MOS Technology & the 6502 (Commodore.ca)

En memoria de Chuck Peddle (R.I.P.)

Publicado originalmente en la serie Bicentenario de FayerWayer. Septiembre, 2019