Preguntilla de programación de Arcades

[mentalthink]

Quería haceros está pregunta más que nada por curiosidad referente a las máquinas Arcades...

El asunto es, haya por lo 80 a la par que Spectrum Amsgtrad y demás, las máquina Arcade se programaban en general en ASM, o sabéis si las compañias tenian algún lenguaje propio, lo digo, porque al ser el Hardware normalmente más potente que en los ordenadores domésticos quizás hacían uso de alguna herramienta especifica...

Supongo que a finales de los 80 y 90, cuando estába el Final Fight y máquinas de ese estilo la programación sería C o alguna cosa asi no?¿.

[mcleod_ideafix]

Por lo que sé, los arcades de la época del PacMan y similares (es decir, principios de los 80) se programaban directamente en ensamblador.

[Ivanzx]

Por lo que sé, los arcades de la época del PacMan y similares (es decir, principios de los 80) se programaban directamente en ensamblador.

Y en z80, si no me equivoco? Por eso tenemos el Pac-Man emulator para Spectrum, y me imagino que bastantes de estas recreativas primigenias podrian ser emuladas igual

[na_th_an]

No es tan fácil. Se pudo hacer con Pacman porque era sencilla y dejaba tiempo de frame sin hacer nada que se pudo utilizar para emular el hardware gráfico (que además era muy sencillo).

Que yo sepa, todo lo que esté basado en 68000 (desde Pong hasta NeoGeo / CPS2) o menos está programado en ensamblador y, marginalmente, en C. A medida que los procesadores centrales y GPUs fueron más potentes, se fue pasando a C.

Como en las consolas, vaya.

[Rapido]

La gran mayoría de los juegos de la época de los 80 fueros programados en assembler, excepto algún que otro juego que fue programado en C, por ejemplo Marble Madnes,( esto facilito luego el port a las plataformas de 16 bits , amiga, genesis de sega.) Como curiosidad, también cabe reseñar que un puñado de juegos de la década de los 70 y principios de los 80 fueros programados en Bliss, lenguaje de mas alto nivel que apareció antes que C.

Saludos.

[jotego]

Mi experiencia analizando el código fuente de tres juegos de recreativa: Ghosts'n Goblins, Gryzor y Combat School es que los tres muy probablemente se programaron en ensamblador. De haber sido en C, el código desensamblado seguramente tendría un uso mayor de la pila y de llamadas a funciones.

[mentalthink]

Vaya gracias a todos por vuestras respuestas todas muy interesantes...

Curioso lo del Bliss que comenta rápido, en esa Época si que daba por hecho que todo sería en ASM.

Y sobre lo que comentas Jotego, como se saben esas cosillas, como se sabe que si es C o C++ hay más llamadas a la pila y tal, que yo quiero saber esos intringulis que se me escapan, bueno y todo lo que no sé...

[explorer]

Yo he desensamblado parte de las ROM del Pengo (Sega, 1982) y puedo decirte que lo hicieron en ensamblador.

Ahora bien... la mayor parte de los compiladores modernos de C admiten la incorporación de la función asm(), que permite escribir en lenguaje ensamblador dentro del propio código C. Eso permite hacer el núcleo del programa en C, y dejar las partes de acceso al hardware o partes críticas en el tiempo, interrupciones... para hacerlas en ensamblador.

Hoy en día se puede programar para ese hardware con el compilador ZCC. Por ejemplo, en esta página hay enlaces a herramientas y ejemplos de cómo programar en el hardware del Pac-Man y del Pengo. Aquí hay más.

Lo malo es que... a esas páginas y herramientas le quedan dos telediarios para que desaparezcan. Parece que no hay mucho interés, lo cuál es una pena.
Pero seguro que hay otras herramientas en otros sitios (pero que no he sido capaz de encontrar).

[na_th_an]

Vaya gracias a todos por vuestras respuestas todas muy interesantes...

Curioso lo del Bliss que comenta rápido, en esa Época si que daba por hecho que todo sería en ASM.

Y sobre lo que comentas Jotego, como se saben esas cosillas, como se sabe que si es C o C++ hay más llamadas a la pila y tal, que yo quiero saber esos intringulis que se me escapan, bueno y todo lo que no sé...

Echando un vistazo al código, un programador de ensamblador puede reconocer las trazas de una generación automática de código: Si todos los bucles son iguales, si hay repetición de bloques de código, si ves que se utiliza mucho la pila...

Por ejemplo, cuando una función de C necesita variables locales hace espacio en la pila, nada más empezar. Si por un lado ves que el programa tiene muchas "subrutinas" y todas o casi todas empiezan reservando espacio en la pila y luego en el código ves muchos accesos a la parte de la pila que se ha reservado, es casi seguro que ese programa estuvo escrito en C u otro lenguaje similar y que el código que ves lo ha generado un compilador.

Cuando programas ensamblador a mano, sabes qué quieres hacer y buscas la mejor forma de hacerlo. Un compilador puede contar con un optimizador para intentar mejorar algo el código que genera, pero por lo general se limita a traducir lo mejor que puede de forma, digamos, puramente sintáctica. Tú a lo mejor vas a hacer un bucle y reaprovechas un registro para el índice y para generar un puntero... pero para el compilador todas las variables son iguales y probablemente haga un acceso a memoria para guardar el índice. De la misma manera, si sabes que vas a seguir operando con el mismo operando durante un tiempo, te lo guardas en un registro y vas almacenando los resultados parciales en el mismo registro... Un compilador (sin optimizar, que ahora los optimzadores son bastante listos), por lo general, irá a la pila a buscar el valor, lo pasará a un registro, le hará la operación, y lo volverá a almacenar... para cada operación, aunque vayan todas seguidas.

[mentalthink]

Gracias Explorer si El czz y el zcc los conozco pero el de C++ lo veo un poco lio, incluso más que lo poco que se de ASM... supongo que una alternativa es usar Basic compilado, que curiosamente el otro día encontré una web que hacen un profundo examen a un Basic y parece que va bastante bien, de hecho hice un par de pruebas y es muy rápido FABACOm creo que es, eso si en el emulador hace un poco el cabra, supongo que en la máquina real debe ir bien...

Nathan gracias por la explicación, creo que he pillao bien lo que me querías comentar... es curioso como cuando se ven las cosas desde dentro no son tan extremadamente complejas como parecen...

Gracias de nuevo a todos.