Emulación del puerto $FF

Avatar de Usuario
zx81
Mensajes: 134
Registrado: 23 Feb 2013 21:31

Re: Emulación del puerto $FF

Mensajepor zx81 » 08 Ene 2014 11:21

Último mensaje de la página anterior:

antoniovillena escribió:Están muy bien pero, ¿no te sería más facil hacer la modificación sobre emulador completo como Fuse?. Lo digo porque Ticks no emula nada que no sea el Z80 y completarlo para convertirlo en un emulador completo te va a llevar más tiempo que partiendo de otro. Desde luego sería una utilidad interesante porque hasta hoy que yo sepa nadie lo ha hecho. Otra cosa sería cuántos usuarios estarían dispuestos a utilizarla y cuáles serían sus usos prácticos, pero ya te digo sólo con que la utilices tú y sólo por el mero hecho de hacerla es suficiente para darte por satisfecho.


Desde el principio he dicho que quizá lo mejor sería tener un emulador, no modificar directamente ticks. A fin de cuentas, ticks es uno de tus niños y tú decides lo que le pones. Afortunadamente, tampoco necesito modificar Fuse, para lo que además necesitaría la autorización de su autor, porque para eso tengo mi propio emulador. :)

Sobre cuanta gente lo gastaría sería poca, eso seguro, porque los que desarrolláis para el Spectrum sois muchos menos de los que solo juegan. Me interesa más la opinión de los expertos del foro, si les parece útil o no y en qué forma. Lo de hacerlo o no... ya veríamos. Siempre he tenido el convencimiento de que el core Z80 que tiene JSpeccy debería ser bastante distinto dependiendo de la situación. Si es para jugar, uno. Si es para desarrollar, otro. El de "jugar" está más centrado en conseguir velocidad a toda costa, el otro debería hacer más fácil la depuración y traza de programas, y no es trivial.
Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right' and 'build car'.
John Sladek

Empieza a jugar sin tener que compilar: Emulador JSpeccy

Avatar de Usuario
antoniovillena
Mensajes: 122
Registrado: 18 Ago 2012 13:06

Re: Emulación del puerto $FF

Mensajepor antoniovillena » 08 Ene 2014 11:46

Ups, no te había leído bien. Desde luego lo más cómodo sería modificar tu JSSpeccy, así no tienes que lidiar con código ajeno. Se me ocurre que puedes mostrar tres gráficas, una de lectura, otra de escritura y otra de fetch. La de lectura y fetch sería un gráfico de 256x256 pixels y la de escritura de 256x192 (o como las otras si quieres incluir las escasas escrituras a ROM). Usas 3 arrays de bytes, por cada acceso incrementas el contador del array y en caso de llegar a 255 mantienes dicho valor (que indica que han ocurrido más de 254 accesos). Luego a la hora de pintar el gráfico usas escala de grises desde 0 a 254 y un color chillón (rojo) para el valor 255 indicando el overflow. Las zonas de fetch deberían tener aspecto de nube de puntos dispersa, puesto que las instrucciones tienen normalmente entre 1 y 4 bytes, o también puedes incrementar todas las posiciones de los bytes de la instrucción (no solo la primera) y así tener un aspecto continuo en la gráfica.

No sé, es sólo una idea, a lo mejor es preferible un array de 16 bits porque sea muy común el overflow y usar la escala de grises en forma logarítmica y no lineal. Todo es cuestión de hacer pruebas.

Avatar de Usuario
ron
Mensajes: 17036
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 457 veces
Agradecimiento recibido: 472 veces

Re: Emulación del puerto $FF

Mensajepor ron » 08 Ene 2014 18:58

ZX81, una pregunta !

Basándome en experiencias de otros coders que han decidido portar sus emus de Java a C, ganando mucho y teniendo un nuevo emulador que no depende de un runtime de ejecución, que además podrás compilar en Linux, Win y Mac ¿ porque no portas tu JSSpeccy a C ?

Tan solo es saber que opinas al respecto y que pasa por tu cabeza, ya que tu JSSpeccy a mi me parece un buen candidato a ello.

Avatar de Usuario
zx81
Mensajes: 134
Registrado: 23 Feb 2013 21:31

Re: Emulación del puerto $FF

Mensajepor zx81 » 08 Ene 2014 20:57

ron escribió:ZX81, una pregunta !

Basándome en experiencias de otros coders que han decidido portar sus emus de Java a C, ganando mucho y teniendo un nuevo emulador que no depende de un runtime de ejecución, que además podrás compilar en Linux, Win y Mac ¿ porque no portas tu JSSpeccy a C ?

Tan solo es saber que opinas al respecto y que pasa por tu cabeza, ya que tu JSpeccy a mi me parece un buen candidato a ello.


Originalmente, allá por el siglo pasado, yo quería hacer un emulador en C++ usando las librerías Qt. De hecho, ftp://ftp.worldofspectrum.org/pub/sincl ... 0.9.tar.gz es el mudo testigo de mis primeras pruebas. Ahora, si tienes tiempo y suficiente curiosidad, intenta hacer una prueba. Te pillas un Linux normalito, especialmente una de estas distribuciones modernas que no te instalan todo por defecto, te bajas el último Fuse y que reto a que lo compiles con soporte de todo lo que puede llevar. En la época en la que Fuse no estaba en los repositorios de las principales distribuciones había que compilárselo uno mismo y te aseguro que no estaba al alcance de mucha gente esa proeza. En esta Fedora 20 que estoy utilizando, Fuse está enlazado con 71 librerías dinámicas diferentes. Y cuando hayas acabado, compílalo en Windows (32 y 64 bits, please) con un compilador que no sea el Visual Studio. Y cuando acabes con ese segundo, lo repites en MacOS-X. Y cuando hayas acabado, te pillas un Unix distinto (AIX, Solaris, HP-UX) y lo compilas también ahí.

Mucho antes de que hayas llegado al final, ya sabrás porqué decidí cambiar de tercio y escribirlo en Java. Como está probado en un montón de sistemas y funciona todo en todas partes, creo que he cumplido con mi objetivo con creces, y eso que no tengo en casa más que Linux para probar. Solo tengo una curiosidad, y es saber cómo se ejecutaría en una máquina con procesador ARM de esas que venden ahora como Smart TV.

Yo no sé en el caso de otros emus de máquinas más complejas cuanto se ganaría por pasarlo a C++ (a C ni se me ocurriría). Pero el consumo de CPU en una máquina dual core a 24 Ghz da como para que a máxima velocidad la carga de cintas funcione al 6000%. Curiosamente, haciendo eso mismo en esa misma máquina, Fuse no va mucho más deprisa (¿se ha molestado alguien en probarlo, o funcionamos únicamente por habladurías como las viejas de los pueblos?). El caso es que yo mismo me obcequé en hacer el core Z80 lo más rápido posible, y luego resulta que haciendo profiling del emulador, un frame tarda habitualmente mucho menos de 2 ms, la décima parte del tiempo.

¿Qué ganaría entonces pasándolo a C++?. ¿Satisfacer a los maniáticos de Java?. Creo que necesito una razón mejor para hacer ese ingente trabajo. Hablamos de más de 20k líneas de código y aún eso no es lo importante, porque muchas cosas, como el sonido, se manejan de manera MUY distinta en Linux, Windows y MacOS-X (por no hablar de otros sistemas), y los compiladores no son todos el GCC, y ni siquiera se puede contar con que siempre tengas la última o penúltima versión de GCC, lo que significa multiplicación de problemas. Como sería un emulador "nuevo", no estaría en los repos de las distros de Linux, con lo que la gente se lo tendría que compilar ella misma (la situación de Fuse hace aún menos de 5 años).

Si hubiera visto que el emulador, haciendo lo máximo posible de que hubiera sido capaz, funcionaba a paso de tortuga y que resultaba inútil, hubiera cambiado de tercio. Pero es que se ha probado en máquinas de hace cerca de 10 años y funciona al 100% de velocidad (aunque cargue a solo el 900%). Java existe en casi todos los sistemas populares y es gratis (y será, porque la OpenJDK se encarga de eso). Esconde todas las diferencias grandes y pequeñas entre sistemas y me puedo centrar en lo que importa, cosa no baladí en un proyecto que cada vez es más grande y el que lo mantiene es uno solo.

Ahora soy yo el que pregunta para que se le responda con la mayor sinceridad, ¿existe alguna razón técnica de peso y bien fundada para hacer el trabajazo que supone reescribir el emulador en C++?- Awaiting answers...
Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right' and 'build car'.
John Sladek

Empieza a jugar sin tener que compilar: Emulador JSpeccy

Avatar de Usuario
ron
Mensajes: 17036
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 457 veces
Agradecimiento recibido: 472 veces

Re: Emulación del puerto $FF

Mensajepor ron » 08 Ene 2014 21:15

zx81 escribió: Solo tengo una curiosidad, y es saber cómo se ejecutaría en una máquina con procesador ARM de esas que venden ahora como Smart TV.


Hmmmm, y porque no Raspberry Pi.


zx81 escribió:Ahora soy yo el que pregunta para que se le responda con la mayor sinceridad, ¿existe alguna razón técnica de peso y bien fundada para hacer el trabajazo que supone reescribir el emulador en C++?- Awaiting answers...


Yo en su día me descargué el source del Fuse y del FBZX. Éste último me gustó ya que tira de las libs SDL y me dió por portarlo y compilarlo en Dreamcast.

http://www.youtube.com/watch?v=bJtGlVF2iDU

Ahí lo tienes rulando en una dreamcast que tiene 16MB de RAM y le sobraba mucha. Ciertamente lo hice como entretenimiento ya que estaba en otros proyectos como el DragonDC o el EnterpriseDC y necesitaba aprender y probar cosas y esto me vino de lujo. Pero claro, el pero está en las LibSDL, a mi particularmente me encantan y si funcionan en un SH4 a 200 Mhz que no harán en un ARM7.

En este video se ve una versión muy primitiva, sin depurar, una compilación a groso modo tan solo para comprobar como funcionaban ciertas cosas y para contrastar el funcionamiento. La verdad que me vino de perlas. NO deja de ser un port rápido y además funciona. Tampoco era un emulador que se pudiera publicar ya que ese no era su fin.

Si, es una currada, no dudo que haya que echar tiempo y canas, pero tu emulador hace cosas que otros no hacen, y de momento desconozco si ya lo hacen, como lo de emular el el CP/M de Jiri Lamac. No se si eso te serviría de aliciente.

Avatar de Usuario
zx81
Mensajes: 134
Registrado: 23 Feb 2013 21:31

Re: Emulación del puerto $FF

Mensajepor zx81 » 08 Ene 2014 22:20

ron escribió:
zx81 escribió: Solo tengo una curiosidad, y es saber cómo se ejecutaría en una máquina con procesador ARM de esas que venden ahora como Smart TV.


Hmmmm, y porque no Raspberry Pi.


La Rpi no estaba mal cuando salió, pero ahora cualquier móvil de gama media-baja es el doble de potente o más y no cuesta el doble. Creo que la última versión de java para ARM ya permite ejecutar la parte gráfica (Swing) en la Rpi, pero no he investigado eso. Si alguien tiene una y le apetece.. ;)

ron escribió:Yo en su día me descargué el source del Fuse y del FBZX. Éste último me gustó ya que tira de las libs SDL y me dió por portarlo y compilarlo en Dreamcast.

...

no dudo que haya que echar tiempo y canas, pero tu emulador hace cosas que otros no hacen, y de momento desconozco si ya lo hacen, como lo de emular el el CP/M de Jiri Lamac. No se si eso te serviría de aliciente.


Bien, buen intento, has contado una experiencia y has mostrado tu preferencia por la SDL que yo no utilizaría porque me decantaría por la Qt. Realmente, ¿vale la pena sacrificar funcionalidades en las versiones para ordenadores actuales solo por poder compilar en la DC?. ¿Es esa una razón de peso para reescribir más de veinte mil líneas?

P.D.: Hoy he descubierto que hay otro emulador que soporta LEC, aunque en version beta y parado hace más de un año, el X128 de James McKay, todo un clásico.
Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right' and 'build car'.
John Sladek

Empieza a jugar sin tener que compilar: Emulador JSpeccy


Volver a “Software Spectrum”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado