Emulador de CHIP8 en basic

[Hark0]

Así, calculando rápido, 64x32 pixels en monocromo ocuparían 256 bytes.

Cierto qué torpeza!

-- Actualizado 13 Dic 2013, 11:05 --

Por cierto que aqui: http://chip8.wikia.com/wiki/Chip8 se comenta DONDE se alojan los datos en la RAM... por lo que veo cada máquina lo ubicaba en un sitio... ¡Viva la compatibilidad!

[Hark0]

Bueno, ayer por la noche empece a escribir mi emulador de Chip-8, siguiendo la descripción de la máquina y los opcode...

He ojeado tanto código fuente, entre ellos el de @Jepalza claro, que quiero hacerlo sin mirar más fuentes, SOLO con lo que diga la wikipedia...

De momento MAZE funciona y INVADERS arranca, dibuja la pantalla intro y salta a ejecutar... me falta implementar la parte del interface de teclas...

Si tengo tiempo esta tarde le meto mano, a ver si lo termino... y subo pantallas, etc.

[jepalza]

Bueno, ayer por la noche empece a escribir mi emulador de Chip-8, siguiendo la descripción de la máquina y los opcode...

He ojeado tanto código fuente, entre ellos el de @Jepalza claro, que quiero hacerlo sin mirar más fuentes, SOLO con lo que diga la wikipedia...

De momento MAZE funciona y INVADERS arranca, dibuja la pantalla intro y salta a ejecutar... me falta implementar la parte del interface de teclas...

Si tengo tiempo esta tarde le meto mano, a ver si lo termino... y subo pantallas, etc.

A ver cómo te sale.
Si te sirve de algo, antes de hacer este emulador, allá por el 99 o 98, ya había hecho unos cuantos en "C", de máquina arcade, o sea, que cuando hice este, me pareció de lo mas simple y divertido, en comparación con los de "C"

[Hark0]

Como ya comente, me parecio que esta cpu era de lo mas basico... corrigeme si todavia la hay mas "simple"...

A ver si luego tengo tiempo y me pongo un rato... este finde ha sido imposible...

[Hark0]

Bueno, he estado a ratos programando mi CPU Chip-8. He implementado todos los opcode, montado el mainloop, etc...

He cargado bastantes ROMs, y aparentemente el emulador funciona.. lento porque no he optimizado nada. Me interesaba ver antes su fucnionamiento...

PERO

tengo un problema con la rutina de video, que creo que no acabo de programar bien. ¿Como lo he hecho?

He montado una superficie bitmap y sobre ella incializo el video al arrancar el emulador. La ram de video la seteo a 0 completamente.

Cuando empieza el programa y llega a una instrucción de pintado de sprites, la rutina lo ejecuta correctamente, pero me he encontrado con ROMs que al dibujar no borran la pantalla por su cuenta, por lo que el display muestra dibujos mezclados (por la función XOR).

Según el manual original, ESTO ES ASI; si se redibuja un mismo sprite en la misma posición SE HA DE BORRAR. De hecho testee la rutina de render con el programa de ejemplo que viene en el manual del Cosmic...

La pregunta es: independientemente de que esté o no especificado ¿debo borrar la pantalla por mi cuenta? Me refiero al doble buffer, para evitar que los sprites se solapen...? Cada 60hz?

Credo que esto puede añadir un efecto de flickering no deseado...

Si alguien me echa una mano... perfecto... cuando tenga un minuto subo pantallazo...

PD @Jepalza, programar este tipo de software es todo un vicio... más que nada por la parte de investigación acerca del hard, historia, evolución, etc...

[Zardoz]

Pruébalo, pero déjalo como una opción en el arranque. Así se puede activar para apañar los juegos que dan problemas.

[jepalza]

¿que te val lento en basic? me dejas anonadado. ¿cómo lo has hecho? Si ese emulador con lo "cacurrio" que es, un PC moderno se lo come con patatas.

Lo de la pantalla, a mi me ocurrió igual, pero la borraba yo antes de dibujar la segunda pasada. Lo haces en oculto, la vuelcas a visible, y ni se nota.

[Hark0]

¿que te val lento en basic? me dejas anonadado. ¿cómo lo has hecho? Si ese emulador con lo "cacurrio" que es, un PC moderno se lo come con patatas.

Lo de la pantalla, a mi me ocurrió igual, pero la borraba yo antes de dibujar la segunda pasada. Lo haces en oculto, la vuelcas a visible, y ni se nota.

Cuando digo lento, no digo leeeeeeeeeento, va decente, lo que pasa es que estoy pintando todas las variables en pantalla para "ver" sus valores en todo momento No me preocupa eso de momento...

Sobre la pantalla, habia pensado precisamente en eso, en hacer un doble buffer y trabajar "por detras" con él, y volcar sobre pantalla principal...

Como ha comentado @Zardoz, lo añadiré como opcional, a ver que tal...

Gracias!

[jepalza]

Cuando digo lento, no digo leeeeeeeeeento, va decente, lo que pasa es que estoy pintando todas las variables en pantalla para "ver" sus valores en todo momento No me preocupa eso de momento...

uffff, ya decía yo.
Eso sí lo entiendo, por que en mis emus pasa igual. Enviar muchos textos, a cada milisegundo enlentece todo un montón.
En emuladores mas gordos, como el del 68000 que aún no he acabado (ni acabaré), era tan sumamente lento (el macintosh plus tardaba casi un minuto en dibujar la pantalla), que le puse una condición de poner textos de depuración, solo cada "x" veces, por ejemplo, cada 100 veces, pero el problema entonces, es que la salida de depuración ya no es en tiempo real, cada ciclo, y cuando aparece el texto, te has saltado 100 instrucciones, con sus 100 pasos.
Pero para salir del paso servía.

Ahora que recuerdo, en algún emul encontré una forma de enviar textos que no fuera con las genericas del msdos (vamos, con el PRINT), sino con un comando que generaba sus propios textos en modo gráfico, pasando de las llamadas de MSDOS, y era mil veces mas rápido, pero el problema que tenía, es que ya no servía el LOCATE para situar el texto, y debía de hacerse mediante coordenadas gráficas, que era mas incómodo. Por ejemplo, si haces dos PRINT seguidos, el segundo baja la línea el solo, en cambio, con el otro método, el segundo aparecía "mezclado" con el primero.

[Hark0]

Lo mismo hago yo... llenar en exceso la pantalla de prints y encima en decimal / hex a la vez...

;D