ZonaDeVicio - Tu comunidad de videojuegos online - Blogs - pSMS WIP por Puck2099 https://www.gp32spain.com/foros/blog.php?2841-pSMS-WIP Tu comunidad de videojuegos en Internet. es Tue, 07 Apr 2026 15:27:23 GMT vBulletin 60 https://www.gp32spain.com/foros/images/misc/rss.jpg ZonaDeVicio - Tu comunidad de videojuegos online - Blogs - pSMS WIP por Puck2099 https://www.gp32spain.com/foros/blog.php?2841-pSMS-WIP Acabo la carrera y sigo con mi proyecto de emulador https://www.gp32spain.com/foros/entry.php?1825-Acabo-la-carrera-y-sigo-con-mi-proyecto-de-emulador Tue, 24 Jun 2008 12:31:57 GMT Pues sí, hoy he ido a ver mi última nota y, a falta de entregar una práctica que tengo medio hecha en Septiembre, ya solo me queda el proyecto (o TFC) para que me den el título de ingeniero :angel1: Bueno, dicho lo cual, el motivo de este hilo era comentar a los que siguieron... Pues sí, hoy he ido a ver mi última nota y, a falta de entregar una práctica que tengo medio hecha en Septiembre, ya solo me queda el proyecto (o TFC) para que me den el título de ingeniero :angel1:

Bueno, dicho lo cual, el motivo de este hilo era comentar a los que siguieron mis entradas en el blog sobre el emulador de Master System que voy a presentar como TFC (al final le he cambiado el nombre a gSMS) que a partir del 1 de Julio (que me voy al pueblo) me pondré a saco con él y espero mantener un ritmo de actualizaciones casi diarias (lo tuve que dejar "aparcado" por la sobrecarga de prácticas y exámenes).

Por otro lado, he decidido "migrar" el blog a Blogger, pues así tengo algo más de control sobre el mismo y, sobre todo, le resultará más cómodo a varios amigos u otra gente interesada que no puede verlo correctamente aquí sin estar registrada (no se muestran imágenes por ejemplo).

La nueva dirección es: gSMS WIP y si alguien se quiere apuntar directamente a los feeds: atom.

Saludos :brindis: ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1825-Acabo-la-carrera-y-sigo-con-mi-proyecto-de-emulador El pseudo anteproyecto https://www.gp32spain.com/foros/entry.php?1380-El-pseudo-anteproyecto Wed, 05 Mar 2008 20:54:19 GMT Ya sé que hasta no tener aprobado todo lo obligatorio y troncal (me faltan dos asignaturas de segundo) no se puede presentar el anteproyecto, pero mi tutor me pidió un texto explicando qué era exactamente lo que quería hacer para situarse en contexto, así que esto es lo que le... Ya sé que hasta no tener aprobado todo lo obligatorio y troncal (me faltan dos asignaturas de segundo) no se puede presentar el anteproyecto, pero mi tutor me pidió un texto explicando qué era exactamente lo que quería hacer para situarse en contexto, así que esto es lo que le llevaré mañana.

Os lo pongo por aquí para ver si antes de dos horas que lo imprima veis que me falta algo o algún cambio que creáis necesario.

El profesor da asignaturas de compiladores, intérpretes, máquinas virtuales, etc., así que supongo que entenderá los términos de los que hablo (aunque algunos los he puesto más en lenguaje de su campo).

Este proyecto consiste en la realización de un emulador de la videoconsola SEGA Master System programado en el lenguaje C++ utilizando una metodología orientada a objetos.

Si bien la versión que se presentará funcionará bajo el sistema operativo GNU/Linux y arquitectura x86, la realización de este emulador se hará con el propósito de ser fácilmente portable a otros sistemas operativos y/o arquitecturas.

Un emulador consiste en la implementación mediante software de una máquina completa, creando una máquina virtual que reproduce de la manera más fiel posible el comportamiento de cada uno de los componentes de la máquina física real.

En el caso particular de este proyecto, la máquina a emular es la videoconsola Master System de la compañía japonesa SEGA. El emulador a construir deberá reproducir el comportamiento de cada uno de los componentes de dicha videoconsola (microprocesador Zilog Z80, controlador gráfico, controlador de sonido, etc.) con el objetivo de ser capaz de ejecutar correctamente los programas (juegos) que originalmente se escribieron para la misma.

Estos programas, originalmente almacenados en una memoria ROM situada en el interior de los cartuchos en los que se distribuían, serán interpretados por el componente correspondiente al procesador Z80 (están escritos en su lenguaje máquina) el cual interactuará con el resto de componentes que forman el emulador para obtener unos resultados idénticos a los de la máquina real.

Así mismo, se incorporarán en la medida de lo posible otras características adicionales no presentes en la máquina original pero que pudieran mejorar la experiencia como filtros gráficos, reescalados de imagen, etc.

El emulador contará además con una interfaz gráfica de usuario, de modo que sea posible su configuración, carga de programas y ejecución de forma sencilla usando solamente el ratón.

Por otro lado, para depuración de los módulos incluidos se crearán las herramientas que se estimen necesarias (interfaz interactivo para el Z80, desensamblador, etc.) que también serán incluidas junto con el resto de documentación.
Please, opinad :brindis: ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1380-El-pseudo-anteproyecto Arquitectura del Z80 (Parte II) https://www.gp32spain.com/foros/entry.php?1363-Arquitectura-del-Z80-(Parte-II) Tue, 04 Mar 2008 20:17:29 GMT Con las clases no me queda mucho tiempo libre, pero aun así he conseguido avanzar un poco más en la comprensión del Z80, hoy voy a comentar las *interrupciones*. Una interrupción es una señal por la cual se interrumpe momentáneamente el secuenciamiento del programa, se trata... Con las clases no me queda mucho tiempo libre, pero aun así he conseguido avanzar un poco más en la comprensión del Z80, hoy voy a comentar las interrupciones.

Una interrupción es una señal por la cual se interrumpe momentáneamente el secuenciamiento del programa, se trata dicha interrupción mediante una rutina y después se vuelve al punto donde se interrumpió.

Como ya comenté previamente, en el Z80 tenemos 2 biestables (dispositivos que almacenan un bit) llamados IFF1 y IFF2. El primero se usa para indicar si las interrupciones enmascarables (las que pueden ignorarse) están habilitadas (IFF1=1) o inhibidas (IFF1=0) y el segundo nos servirá como respaldo del primero (ya veremos luego como).

Hay dos tipos de interrupciones: enmascarables (INT) y no enmascarables (NMI). La diferencia entre ambas es que las primeras pueden ignorarse si así se configura el computador y las segundas hay que tratarlas obligatoriamente.

Para habilitar las INT se usa la instrucción EI que pone a 1 los biestables IFF1 y IFF2, mientras que para inhibirlas usaremos la instrucción DI que los pone a 0.

Interrupción no enmascarable
Cuando se produce una NMI el procesador sigue los siguientes pasos:
  1. Salvaguarda el contador de programa (PC) en la pila.
  2. Guarda el valor de IFF1 en IFF2 y pone IFF1=0 (inhibe INT).
  3. Pone PC=0x0066 (Salta a la dirección 0x0066).

Una vez realizado este proceso, en la dirección 0x0066 estará la rutina correspondiente a su tratamiento. Cabe fijarse que no se puede interrumpir a una NMI con una INT porque pone IFF1 a 0.

Finalmente, cuando acabe la rutina de tratamiento de interrupción se ejecutará la instrucción RETN que copia IFF2 en IFF1 (restaura el valor guardado) y restaura el PC desde la pila para continuar la ejecución donde se quedó.

Interrupción enmascarable
Hay tres modos diferentes en que puede estar el procesador para atender a las INT, estos modos llamados 0, 1 y 2 se establecen con las instrucciones IM0, IM1 y IM2.

Modo 0
Es similar al modo del 8080 de Intel, el dispositivo que genera la INT pondrá un código de operación de una instrucción en el bus de datos (normalmente una llamada a subrutina) y a partir de ahí seguirá la ejecución.

Modo 1
Es análogo al tratamiento de las NMI, solo que ahora se salta a la dirección 0x0038 y es enmascarable.

Modo 2
En este modo se usan interrupciones vectorizadas.

El dispositivo pone en el bus de datos un byte. Este byte se tratará como la parte baja de una dirección (recordemos de 16 bits) y el valor del registro I como la parte alta de dicha dirección. Finalmente, se pondrá a 0 el bit menos significativo para que sean direcciones pares.

En esta dirección se encontrará la dirección de la rutina de tratamiento de interrupción adecuada a la que se saltará (previa salvaguarda del PC en la pila).

Consideraciones
Eso sería básicamente todo el tema de las interrupciones, cabe destacar que las interrupciones no enmascarables pueden ser anidadas (una interrupción interrumpe a otra), pero no pueden saltar si se está tratando otra no enmascarable.

Finalmente, he buscado en varios libros y no he encontrado ninguna referencia a que se haga un guardado automático del registro de flags (F) en la pila a semejanza de como ocurre con el PC, así que supongo que será cuestión del programador el contemplar su salvaguarda.

Hasta aquí por hoy :brindis: ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1363-Arquitectura-del-Z80-(Parte-II) Arquitectura del Z80 (Parte I) https://www.gp32spain.com/foros/entry.php?1346-Arquitectura-del-Z80-(Parte-I) Sun, 02 Mar 2008 20:27:24 GMT Vamos a hablar un poco del "cerebro" de la Master System: el Z80. Si bien algunos términos quizá sean algo técnicos o sea de muy bajo nivel, he procurado dar algunas explicaciones que para quien controla del tema serán superfluas, pero pretenden ayudar un poco a quien todo esto le suene a chino pero tenga interés en aprender. Si algo no queda claro, please, avisadme en los comentarios para intentar explicarlo :brindis:

El Zilog Z80 es un micro catalogado a veces como de 8 bits (todavía no entiendo en base a qué se hace ese tipo de catalogaciones, pero bueno), poseyendo un bus de direcciones de 16 bits y un bus de datos de 8 bits.

Veamos un esquema explicativo:


Como podemos ver, contamos con los siguientes registros accesibles:
  • B, C, D, E, H, L y B', C', D', H', L'. Estos registros son de 8 bits, pero pueden agruparse por pares en registros de 16 bits de la forma BC, DE, HL y B'C', D'E', H'L'. Tienen la particularidad de que solo son accesibles a la vez 6 de ellos, pues están divididos en 2 bancos intercambiables por medio de unas instrucciones.
  • A, F y A', F'. Como en el caso anterior se trata de registros de 8 bits de los que solo dos son accesibles al mismo tiempo por estar divididos en bancos. El registro A es el acumulador que, como podemos ver en el gráfico, siempre será unos de los operandos de la ALU (Unidad Aritmético Lógica). Por su parte, en el registro F se encuentran los flags de la máquina que guardan su estado.
  • PC. Contador de programa, apunta a la dirección de la siguiente instrucción a ejecutar, por lo tanto tiene que ser de 16 bits.
  • SP. Puntero de pila, apunta a la primera dirección libre de la pila de ejecución, por tanto es necesario que también sea de 16 bits.
  • IX e IY. Estos dos registros de 16 bits se usan como dirección base para instrucciones que hacen uso de vectores. Como podemos ver, existe una mini ALU que solo sirve para sumarle un dato de 8 bits a estos registros y volcar el resultado al bus de direcciones.
  • I. Este registro de 8 bits se usa para el tratamiento de interrupciones.
  • R. Este registro de 8 bits se usa como salida para refrescar memorias externas.


A su vez el registro F se divide en:
  • Bit 7: Flag S. Es el flag que indica el signo, es decir, una copia del bit más significativo de la última operación de la ALU.
  • Bit 6: Flag Z. Este flag indica si el resultado de la última operación es cero.
  • Bit 5: Flag 5. Este bit en algunos documentos dicen que tiene un valor aleatorio, pero en otros he leído que guarda una copia del bit 5 del resultado de la última operación.
  • Bit 4: Flag H. Guarda el acarreo del bit 3 al 4 de la operación (supongo que será útil para operaciones en BCD).
  • Bit 3: Flag 3. Este bit en algunos documentos dicen que tiene un valor aleatorio, pero en otros he leído que guarda una copia del bit 3 del resultado de la última operación.
  • Bit 2: Flag P/V. Dependiendo de la operación, en este bit se muestra si el resultado tiene paridad par (existe un número par de 1s en el registro) o bien hubo desbordamiento.
  • Bit 1: Flag N. Se activará si la última operación fue una resta.
  • Bit 0: Flag C. Es el bit de acarreo, se activará si el resultado de la operación no entra en el registro.


Por otro lado, hay otros registros temporales como W y Z que se utilizan para operaciones internas a las instrucciones y, de momento, no he visto que me vayan a ser de utilidad (programaré el resultado final sin hacer uso de ellos a menos que sea necesario).

Una vez visto esto, cabría plantearse cómo implementarlo dentro del emulador.

Mi idea es agruparlo todo, junto a otra información de estado (como los biestables IFF1 y IFF2 que controlan las interrupciones) que vaya viendo más adelante, dentro de una misma estructura de datos. Con esta agrupación sería muy sencillo cargar o salvar el estado interno, útil para transmitir esa información a otra aplicación (como la GUI de la que hablé en la entrada anterior) o bien para los famosos savestates de las partidas.

La siguiente pregunta que me hice fue: ¿qué sería más conveniente para almacenar los registros de 8 bits que pueden agruparse en pares? ¿un tipo de 8 o 16 bits?

La respuesta es sencilla: ambos. En C existe un tipo de estructuras llamadas union en las que puedes declarar varios tipos que comparten la memoria de dicha estructura, es decir, en una estructura union de 16 bits se podría acceder a los 16 bits de golpe (por ejemplo si fuera el par DE) o bien a los 8 bits superiores (D) o los 8 bits inferiores (E).

Creo que esto es suficiente por hoy, mañana, si tengo tiempo, más. ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1346-Arquitectura-del-Z80-(Parte-I) Buscando una biblioteca gráfica https://www.gp32spain.com/foros/entry.php?1341-Buscando-una-biblioteca-gráfica Sat, 01 Mar 2008 23:19:45 GMT Si por algo destacan los (pocos) emuladores que hay de Master System para GNU/Linux es por su falta de interfaz gráfica (tan solo conozco con ella el Mekanix, port de Meka para Linux que me funciona fatal y nunca he conseguido que reproduzca sonido), así que ese es uno de los... Si por algo destacan los (pocos) emuladores que hay de Master System para GNU/Linux es por su falta de interfaz gráfica (tan solo conozco con ella el Mekanix, port de Meka para Linux que me funciona fatal y nunca he conseguido que reproduzca sonido), así que ese es uno de los aspectos en los que quiero incidir.

El primer componente del emulador que quisiera programar es el núcleo del Z80, pero en lugar de programarlo del tirón me gustaría ir implementándolo poco a poco a medida que lo voy testeando. Podría ir depurándolo con gdb u otro depurador similar y ver cómo cambia el estado interno, pero he pensando en hacer una interfaz que haga uso de él y donde pueda ver el estado de cada registro, memoria, etc.

Mi primera aproximación era hacerlo en modo texto para ejecutarse via terminal, pero, pensándolo mejor, ya que implementaré una interfaz gráfica para el emulador, ¿por qué no ir cogiendo experiencia haciendo otra para depurar el Z80?

Como ya dije anteriormente, mi idea es hacer un emulador para GNU/Linux, pero con la idea de ser relativamente portable a otras plataformas, así que inicié una búsqueda de bibliotecas gráficas con estas características.

Después de unas horas mi cerco se redujo a tres candidatas: Qt4, GTK+ y wxWidgets.

Las tres parecían bastante apropiadas, pero tras consultar opiniones se me ocurrió probar Qt4 y quedé prendando (espero que no me lea efegea :angel1:).

El hecho de estar pensada para usarse con C++ era un punto a favor, pues ya comenté que voy a hacer este emulador con orientación a objetos (quizá no sea lo más óptimo, pero no hay modo mejor de coger práctica con dicha metodología que aplicándola a algo que te gusta), por otro lado es portable, tiene una documentación bastante buena, se obtienen resultados con relativo poco código y trae unas herramientas fabulosas para crear interfaces en un entorno gráfico y el soporte multilenguaje es sencillísimo.

Por otro lado, en mis primeras búsquedas estuve mirando cómo combinar estas bibliotecas junto con SDL para el tema gráfico, pero encontré algunos problemillas de incompatibilidades, así que se me ocurrió otra idea: ¿por qué no usar OpenGL? También es multiplataforma, rápido y seguro que para cosas 2D no será demasiado complicado de usar.

Echando un vistazo a los propios ejemplos de Qt4 he visto que se integra fantásticamente con OpenGL, así que en principio ya tengo seleccionado todo lo necesario para el apartado gráfico.

Bueno, lo siguiente será definir la estructura de datos para representar el estado interno del Z80 y construir el interfaz de depuración que haga uso del mismo, pero antes tengo que buscar mi última versión del GP Lady Killer para mandársela a cierta compañía extranjera...

Mañana, con suerte, más :brindis: ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1341-Buscando-una-biblioteca-gráfica Inicio mi TFC https://www.gp32spain.com/foros/entry.php?1336-Inicio-mi-TFC Fri, 29 Feb 2008 19:52:56 GMT Pues sí, finalmente me he decidido a publicar mi blog con un objetivo claro: mostrar los avances de mi trabajo final de carrera. Ayer jueves fui a hablar con el que sería mi tutor y le propuse hacer un proyecto propio: un *emulador de SEGA Master System*; afortunadamente,... Pues sí, finalmente me he decidido a publicar mi blog con un objetivo claro: mostrar los avances de mi trabajo final de carrera.

Ayer jueves fui a hablar con el que sería mi tutor y le propuse hacer un proyecto propio: un emulador de SEGA Master System; afortunadamente, aunque algo reacio por no entender muy bien de qué se trataba, aceptó llevármelo :brindis:

¿Por qué de Master System? Bien, por dos motivos: uno sentimental, pues fue la primera consola que me regalaron (la Videopac ya estaba en casa desde que tengo uso de razón) y el segundo para empezar con un emulador no demasiado complicado para no tener que emplear dos años en su realización.

Alguno podrá decir que ya tengo mi AlexKidd2X, pero si bien he metido mucho código en él, la mayor parte del código de los chips que integra está hecho por otras personas y mi deseo es hacer uno desde cero (from scratch que dirían los guiris) para aprender todo lo posible.

Así mismo, mi idea es hacerlo para PC y SO GNU/Linux (aunque con la idea de que sea portable) y usarlo por otro modo para aprender y afianzar mis conocimientos en otros aspectos como C++, interfaces gráficas, etc. que me puedan ser útiles para un futuro porque, ¿qué mejor manera de aprender nuevas técnicas que hacerlo aplicándolas a algo que te gusta?

No creo que publique mucho código hasta su finalización (si las cosas no se tuercen estará licenciado con una GPL), pero creo que mis experiencias pueden ser de ayuda para la gente que quiera iniciarse en este mundillo o, simplemente, gente con curiosidad por estos temas.

Finalmente, el nombre código provisional de este emulador es pSMS (de picoSMS o puckSMS, depende de como se mire :angel1:). Acabo de hacer una búsqueda en Google y resulta que hay un emulador de PS2 con ese nombre, así que ya lo cambiaré cuando encuentre uno mejor :p ]]> Puck2099 https://www.gp32spain.com/foros/entry.php?1336-Inicio-mi-TFC