Siempre he querido escribir un emulador desde cero, pero me he resistido durante mucho tiempo porque es probablemente el proyecto de programación más avanzado que he querido hacer. Escoger un sistema para emular no es una opción fácil; el primer proyecto estándar de emulador parece ser un emulador CHIP-8. Así que después de leer mucha documentación, decidí escribir un emulador de Game Boy minimalista, sin soporte para mapeadores personalizados o sonido, al que llamé proyecto Cinoop.
![Escribiendo un emulador de Game Boy desde cero [ENG]](https://cdn.mnmstatic.net/cache/2d/7a/media_thumb_2x-link-2980498.jpeg?1531389427)
Comentarios
Tipica noticia que todo el mundo menea pero no tenemos ni puta idea de que ha hecho y como 😂
#2 Qué ignorante, como si no supiéramos qué es cruzar el Estrecho de Magallanes.
#6 De Elcano en realidad
#8 Magallanes murió tras descubrir el estrecho, así que de Magallanes. Elcano estaba vivo de milagro. Magallanes le perdonó la vida a pesar de haber apoyado un motín.
#20 Hombre que hablaba / escribía en broma
#24 Ya ya, estas cosas empiezan como bromas, y terminamos acuchillándonos en un callejón oscuro.
#2 Hombre te aseguro que alguien hay que lo ha leido y si entiende lo que ha hecho y buena parte del como.
Menudo currazo.
#1 Dicen que escribir un emulador es la prueba de fuego de todo programador de calidad, aunque la GameBoy sea nivel "fácil" dentro de lo que cabe.
#3 nunca lo había escuchado, la verdad.
#3 Para mi la prueba de fuego es escribir un compilador.
#5 el compilador en realidad es aprender una teoría básica y a partir de ahí puedes hacer compiladores como churros. El que de verdad tuvo mérito es el que creo inicialmente toda esa base teórica. Los compiladores no se diferencian tanto unos de otros.
#7 No le quites merito, que para entender esa teoria básica se necesitan los conocimientos de practicamente de toda la carrera, desde las matemática básicas de algebra, teoria de automatas y gramáticas. Despues necesitas conocimientos de programación y del funcionamiento interno de los lenguajes, para finalmente generar un codigo que debe ser optimizado para una arquitectura hardware concreta. Además el compilador no vive solo, sino que convive con unas apis que són las que realmente le dan la funcionalidad requerida.
Evidentemente esto se aprende, ya que la teoria de compiladores ha sido un trabajo incremental de muchas personas, pero dista mucho de ser algo trivial.
#12 parce que has dicho algo y solo has dicho tonterías..
#16 Más razón que un santo.
#12 #7 Para nada es tan dificil si tienes la documentación y sabes perfectamente el funcionamiento del microprocesador o microprocesadores para los que estás haciendo el compilador.
En alguna ocasión he programado en código máquina a nivel de electrónica no de informática, que en el fondo es lo mismo, tienes que dar órdenes al microprocesador de turno para que este haga equis cosa.
Realmente un compilador es un traductor, te voy a poner el ejemplo de una instrucción para un micro con arquitectura MIPS32, que tiene de bueno que es RISC
Por ejemplo, la siguiente instrucción en ensamblador para esta arquitectura.
addi $r1, $r2, 15E
Esta misma instrucción la puedes introducir manualmente en binario directamente a través de las patillas del procesador.
addi = 001000 (La operación u operaciones a hacer, opcode)
$r1 = 00001 (Registro 1)
$r2 = 00010 (Registro 2)
15E = 0000000101011110 (Valor numérico, 350)
00100000001000100000000101011110 (32)
Es una simple traducción de la instrucción en ensamblador a código máquina, claro que hay que saber los opcodes específicos de cada micro, lo mismos con la estructura de las instrucciones y demás, pero eso no es problema si son micros comunes ya que vas a encontrar toda la documentación que quieras y más.
Como puedes ver es una instrucción de 32 bits ya que el micro es de 32 bits, aunque no tiene porque ser siempre así, ya que el puerto de entrada y salida (I/O) del micro puede ser serie, aunque lo normal sigue siendo la transmisión en paralelo, también hay micros que para ahorrar patillaje lo dividen en 2 o más ráfagas de datos (latch)
Cada bit de la instrucción hay que introducirlo por cada una de pines de entrada y salida de datos del micro de forma simultánea, al mismo tiempo. (latch)
#25 los compiladores modernos no son sólo eso, detectan código muerto, pasos innecesarios, tail recursion... Y no hablemos de JIT o de las funcionalidades de gcc de optimizar haciendo profiling... No me parece tan trivial, otra cosa son las prácticas de la carrera.
De todas formas, la prueba de fuego de todo programador creo que debería ser escribir un código fácil de mantener y testear... Y esto si que no es trivial, el resto son detalles de implementación, para mi modo de ver.
#26 Hombre claro, pero quería simplificar al máximo, sin meter programación de por medio y que viera que lo puede hacer él mismo fácilmente, que viera que se puede hacer casi siempre una traducción literal del ensamblador a código máquina.
Otra cosa es que luego quieras añadirle más y más funciones a la función básica del compilador.
#5 Un emulador, un compilador, un interprete, una maquina virtual, un sistema operativo, un driver, un juego "de verdad"...
Hay muchas cosas que pueden servir de "prueba de fuego" todo depende de a que se oriente el interes del programador y las herramientas que use no es lo mismo hacer un juego con opengl en c que usar unity3d.
Lo importante al final es aprender y que sea un proyecto que le haga superarse.
#5 de c++?
#3 es la primera vez que lo oigo
#3 Dicen también que si te mola el mundo de la emulación, el punto de inicio en este mundillo (como desarrollador) es implementar un emulador de Chip8 https://es.m.wikipedia.org/wiki/CHIP-8
#18 Uy perdón si en la noticia ya lo dice.
#1 Es un curro muy gordo, ha debido necesitar una cantidad de tiempo bastante interesante para esto.
Spoiler: cuando toca implementar los opcodes es cuando lo dejas por tedio, y más sabiendo que mucha gente antes ya lo ha hecho en tu lenguaje y estas repitiendo trabajo de chinos.
#14 Se te ve puesto en el tema.
¿Intentaste tú programar alguno por casualidad?
#15 si, de NES y gameboy.
Un coñazo más que otra cosa
#14 Cierto. Precisamente por eso yo me escribí un programita en python que me generaba el código C con la emulación de los opcodes, a partir del nombre del opcode en sí. Fue sin duda la mejor idea que tuve.
Pues yo me he tirado a la piscina, y he empezado con un emulador de PSX directamente. Tengo que decir que los procesadores MIPS son bastante "sencillos" de emular (no así el resto del hardware).