zx81 escribió:De todas formas, entiendo que las Ultracargas, que nunca he usado ni visto, son más útiles en un Spectrum real que en un emulador. En un emulador puedes hacer desde flashloading, al estilo fuse, o simplemente acelerar la emulación lo que haga falta para que cargue en tiempos razonables. En JSpeccy ahora mismo cargo 10 veces más rápido. Para terminar generando un snapshot z80, cualquier cosa vale. Pero un snap z80 no puede cargarse en un Spectrum real, ¿no?.
Un snap Z80 sí puede cargarse en un Spectrum real, con tal de que disponga de DivIDE, o que sea un +2E/+3E. Otros formatos (SNA quizás?) pueden cargarse desde una unidad +D, o un Disciple. No sé si el Mirage Microdriver también tiene algo de esto.
Lo que propone Decicoder es útil, no sólamente para generar ultracargas a partir de TAP's/TZX's, sino también para usuarios de sistemas +3E. Discutí de ello con zxbruno en este hilo de WOS:
http://www.worldofspectrum.org/forums/s ... 464&page=3 . Incluso llegamos a un algoritmo válido para los casos en que no existan multicargas que realizar tras comenzar el juego. Lo que le comenté, en el idioma de Shakespeare, fue esto:
mcleod_ideafix con acento británico escribió:Assuming you want to convert a TAP file to a snapshot format, or a TZX that uses standard ROM routines, a suitable algorithm could be this:
- Start the emulator and autokey the LOAD "" (enter) key sequence (or start the emulator with a preloaded snapshot in which the LOAD "" has just been issued).
- Run the emulator until all TAP blocks have been loaded.
- After the last block has been loaded, continue running until the CPU Program Counter starts executing code from RAM. At that moment, freeze the emulation, get current CPU state and memory and save it all into a snapshot.
The utility that implements this algorithm could have an option to let the user choose at what point the execution should be paused and the snapshot being generated. This way, TZX files with custom loading routines could be used as well.
You could patch the FUSE emulation engine, for instance, to produce this utility, even from command line, no graphic windows really needed for this.
Y en lo que a características de un emulador se refiere, yo aún echo de menos alguna, que no está presente en los emuladores "estrella" para Windows, y son:
- Soporte en DivIDE de tarjetas de memoria reales, no como imágenes. El único que soporta esto, que yo sepa, y con "peros", es el EightyOne.
- Emulación del modo hires de 256x384. Sólo lo soporta EightyOne.
Si alguien pregunta en este punto: "¿y por qué no usas el EightyOne?" le respondo: porque es inestable, y casca con facilidad. Parece ser que su autor ha dejado de soportarlo por problemas personales.
- Soporte, en los que admiten el +3E, de interfaces de 16 bits. Fuse no sé, pero Spectaculator no tiene, y ZXSpin tiene emulación de interfaz CF "barata" de 8 bits.
Las dos cosas anteriores me llevaron a tener que escribir una utilidad que discuto aquí:
viewtopic.php?f=11&t=1472- Emulación fiable de la "lentitud" de dispositivos ATA. Actualmente los emuladores que soporta imágenes de dispositivos IDE, se aserta RDY sin apenas estar tiempo en estado BSY, cuando en un dispositivo real ese tiempo es tangible, y afecta a la velocidad de lectura del dipositivo.
- Sistema de "plugins" documentado, "a la Winamp". De esa forma, un humilde desarrollador de hardware (mí mismo) puede crear un dispositivo tanto en "forma real" como en emulación, para que lo pueda usar todo el mundo, simplemente dando una DLL que el usuario ponga en su carpeta de plugins y active como si "pinchara" el periférico en el bus de expansión. El Fuse permite algo de esto, pero no está documentado (y no, el código fuente no me vale como documentación).
Esto último es, por razones obvias, lo que más me interesa. Sería la puerta a que muchos usuarios probaran cosas que se han hecho, como por ejemplo el Spectranet de Winston. A los propios desarrolladores de hard nos vendría de perlas para depurar el código que maneja el dispositivo, ya que a día de hoy, debemos ser de los pocos que aún hoy depura "a la antigua usanza" por la necesidad de tener que probar el código en un Spectrum real.
- Profiler de Z80, que me diga, en la vista de desensamblador, cuántos T-estados han pasado desde un evento a otro: los eventos podrían ser software (tiempo desde la ejecución de una instrucción en la dirección X hasta la instrucción Y) o mezcla de hard/soft: (tiempo desde que se disparó la interrupción del retrazo vertical hasta la ejecución de la instrucción Y, o tiempo desde que tal puerto de E/S toma cierto valor hasta que se ejecuta cierta instrucción). ZXSpin tiene algo de esto, pero realmente... ¡no sé cómo funciona!
- Una frikada, y seguramente completamente inútil, pero no implementada
: ningún emulador, pero ninguno ninguno, emula el refresco de memoria del 48K. En el EightyOne se emulan cosas tan bizarras como lo de que le des un golpe al "16K memory pack" de un ZX81 y se bloquee por perder contacto en los pines del conector, pero esto no. Ver este post para detalles:
viewtopic.php?f=11&t=394
