Proyecto tontuno... conversor de snapshots a transfer

Emuladores y aplicaciones que ayudarán a la perpetuación del Spectrum y su software en el futuro

Moderador: Sir Cilve Sinclair

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Dom Abr 15, 2018 12:30 pm

Analizando un poco el transfer... a ver si he entendido bien las características principales.

- La rutina en sí solo ocupa 50 bytes.
- Todos los registros (salvo SP y R) se guardan en la pila del programa.
- De la posición SP+18 (siendo SP el valor que se recupera después de cargar el programa), se extrae AF. A se copia a I, pero del supuesto F solo interesa el bit 2 (copia de IFF2).
- La instrucción que establece IM va ubicada en 16386.
- R no se preserva, como tampoco el borde.

Si he entendido bien lo que posteaste, mantransfer era originalmente una utilidad enteramente por software; me pregunto cómo sería de compatible (muchos juegos machacaban toda la memoria al cargar). En caso de que quisieras mejorarla (para poner tu propio transfer en el ZesarUX, aunque teniendo la posibilidad de grabar snapshots es un poco redundante), tengo unas cuantas sugerencias:

- Aunque la rutina de carga solo ocupa 50 bytes (y no usas nada más de la pantalla), te reservas 200 bytes (cargas a partir de 16584). Supongo que podría ajustarse para que la corrupción en pantalla sea menor.
- El transfer usa 24 bytes de la pila en total. Si el tamaño de la pila iba algo justo, puedes sobreescribir partes del programa y hacer que falle. La mayoría de los transfer solo usan 2 bytes de la pila (la dirección de retorno) y meten su propia pila en la pantalla para evitar este problema.
- Si escondes los registros en pantalla, necesitarás un máximo de 80 bytes... de nuevo, se puede mejorar el tema de la corrupción en pantalla.
- No sé hasta cuántos juegos necesitan preservar R... aunque he visto unas cuantas rutinas decodificadoras para las que es imprescindible. En caso de que decidas complicarte la vida y preservarlo, hay que tocar ese JP PO (ya que R avanzará más o menos dependiendo de si se salta o no).
- Si IM x va cargada a martillazos (en una posición fija), lo mismo te quitar el call y meter directamente la instrucción ahí.

La rutina que usas es muy cortita... creo que incluso se podría parchear una ROM de 48k y ponerla como rutina de NMI (al estilo de La Máquina Alucinante). Así tendrías tu propio transfer integrado en un Spectrum real o emulado.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Sab Abr 21, 2018 10:43 am

Me he quedado un poco atascado con la lectura de teclado (ver este hilo). ¿Alguien me ayuda/orienta un poco?

Supongo que si no tengo alguna solución a corto plazo, eliminaré el switch -n y seguiré adelante...
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

kounch
rst 0
Mensajes: 24
Registrado: Mar Dic 05, 2017 8:02 am

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por kounch » Sab Abr 21, 2018 1:58 pm

¿Y si lo cambias para que llegue el dato con el argumento?

Es decir: -n “nombreausar”

En su día yo estuve mirando en Mac y, sin usar soluciones externas (tipo conio.h), era bastante complicado.

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Sab Abr 21, 2018 3:02 pm

kounch escribió:¿Y si lo cambias para que llegue el dato con el argumento?

Es decir: -n “nombreausar”

En su día yo estuve mirando en Mac y, sin usar soluciones externas (tipo conio.h), era bastante complicado.
Esa era la primera opción, pero no me funciona por vago.

Me explico... tal y como funciona la línea de comandos, cualquier cosa que incluya comodines se expande a n argumentos (uno por cada nombre de fichero que coincida con la máscara). De manera que, sin tocar nada, el programa admite el uso de comodines (por eso lo de vago).

Ahora bien, a la hora de hacer funcionar ese -n tengo tres opciones:
- Opción 1: Lo meto como argumento y cuando se use un comodín todas las cintas producidas tendrán el mismo nombre. Que puede o no ser la intención del usuario.
- Opción 2: Por cada fichero pido por teclado el nombre que va a llevar la cinta. Un poco peñazo, pero pones a cada cinta el nombre que debe llevar.
- Opción 3: Obligo al usuario que ponga un nombre de fichero único. Todavía más peñazo, ya que si quieres convertir un directorio lleno de .sna tienes que escribir una línea de comandos por cada fichero.

En principio la idea era usar la opción 2, que era la que me parecía más usable (de ahí mis problemas con el teclado). Y si todas las cintas han de llevar el mismo nombre, casi prefiero ese "Loader" o "Loader48" que es bastante neutro.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Lun Abr 23, 2018 7:16 pm

Todo más o menos arreglado salvo un pequeñísimo detalle...

Me han volado la página web del proyecto. Estaba alojada en 100ws, pero por algún tipo de cambio "a la nube" se la han cepillado y no sé si puedo traerla de vuelta. No es una gran pérdida, ya que tengo todos los ficheros, pero tengo que buscarme un hosting gratuito más fiable (como último extremo podría ponerlo en una Raspberry Pi, pero tampoco me apetece demasiado).

¿Algún sitio gratuito y de fiar?
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zx81
Freddy Hardest
Mensajes: 619
Registrado: Vie Dic 28, 2007 2:14 pm
Ubicación: Valencia
Contactar:

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zx81 » Lun Abr 23, 2018 10:27 pm

Siendo lo que es, yo te diría que github. No es muy complicado crearse un usuario, crear la pareja de claves y subir los fuentes. Todo eso lo haces en una tarde y, de paso, ganas con lo de tener los fuentes controlados.

Si no quieres eso, casi me parece un oxímoron la combinación de "gratuito" y "fiable"....
Debido al fallo de un mecanismo, el lanzagranadas M203 se te podía disparar cuando menos lo esperaras, lo que te habría hecho bastante impopular entre lo que quedara de tu unidad.
Revista del ejército EE.UU. PS, agosto 1993.

Emulador JSpeccy
ZXBaremulator

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por chernandezba » Mié Abr 25, 2018 11:52 am

zup escribió:Analizando un poco el transfer... a ver si he entendido bien las características principales.
He pasado a texto la rutina del mantransfe versión 3:
https://github.com/chernandezba/zesarux ... 3-sp11.asm

Y la versión 2 original:
https://github.com/chernandezba/zesarux ... nsfev2.asm

Esta versión 3 es la que uso dentro de ZEsarUX, es decir, se activa mediante el menú del emulador, por lo que no hay necesidad de gestión de rutina permanente en memoria (eso lo puedes ver en el código de la versión 2)

- La rutina en sí solo ocupa 50 bytes.
- Todos los registros (salvo SP y R) se guardan en la pila del programa.
- De la posición SP+18 (siendo SP el valor que se recupera después de cargar el programa), se extrae AF. A se copia a I, pero del supuesto F solo interesa el bit 2 (copia de IFF2).
Hasta aquí todo correcto, creo :)
- La instrucción que establece IM va ubicada en 16386.
Si, esa instrucción la establezco desde ZEsarUX. Desde software (desde z80) no se puede saber en que modo IM está la cpu. Pero lógicamente como la versión original de mantransfe funcionaba en modo im2 pues no hay necesidad de saberlo. En esta versión que usa ZEsarUX se puede usar tanto en juegos que usen im2 o no.


- R no se preserva, como tampoco el borde.
Correcto

Si he entendido bien lo que posteaste, mantransfer era originalmente una utilidad enteramente por software; me pregunto cómo sería de compatible (muchos juegos machacaban toda la memoria al cargar).
Exacto. La versión que se ejecutaba enteramente en Spectrum (la 2) era un programa residente en memoria que usaba im2. Mediante la detección de unas teclas simultáneas, se grababa el snapshot. Esto funcionaba en todos los juegos que no alteraban las interrupciones (pues se perdería logicamente mi rutina) , además que hay que tener un hueco en memoria que no se tocase (desde la 65230) donde estaba mi programa. Pues hay muchos mas juegos de los que imaginas, jeje, sobretodo los de primera hornada... Recuerdo por ejemplo haber grabado el Maziacs con esto, y unos cuantos mas que ahora no recuerdo ;)
Si lo piensas, no tenía mucha utilidad en su momento, solo fue para quitarme el gusanillo de hacer una rutina así y soñar un poco despierto sin tener un transtape o cualquier otro interfaz de grabación por hardware
Ahora bien, con esta versión 3 integrada en ZEsarUX sí que tiene mas utilidad. Por ejemplo me sirve para convertir un snapshot cargado en memoria a formato tap. Que sí, que ya hay utilidades para esto... pero... desde ZEsarUX cargo el juego en cuestión y puedo grabarlo en archivo tap en cualquier momento. Con esto he probado por ejemplo la demo AY3demo
http://www.worldofspectrum.org/infoseek ... id=0007260
Cargando el .z80 en ZEsarUX, luego grabando un .tap con mantransfe, y de ahí , ese tap lo envío a la SD que tengo en el ZX-Evolution ;)

En caso de que quisieras mejorarla (para poner tu propio transfer en el ZesarUX, aunque teniendo la posibilidad de grabar snapshots es un poco redundante), tengo unas cuantas sugerencias:
No creo que vaya a mejorarla, aunque acepto tus sugerencias :)

- Aunque la rutina de carga solo ocupa 50 bytes (y no usas nada más de la pantalla), te reservas 200 bytes (cargas a partir de 16584). Supongo que podría ajustarse para que la corrupción en pantalla sea menor.
Revisando el código ahora (hace mucho tiempo que no lo miraba) creo que el tema es que al grabar, se transfiere a pantalla (desde ZEsarUX) todo el binario del mantransfe, incluido el programa basic que se carga inicialmente desde el snapshot. De ahí que ocupe mas.
El mecanismo de activación desde ZEsarUX está aquí:
https://raw.githubusercontent.com/chern ... src/menu.c

Función menu_run_mantransfer

Lógicamente el mantransfe original no se transfería todo en pantalla, sólo alteraba dos bytes: 16384 y 16385. El stack usaba el mismo stack que tuviese el juego cargado


- El transfer usa 24 bytes de la pila en total. Si el tamaño de la pila iba algo justo, puedes sobreescribir partes del programa y hacer que falle. La mayoría de los transfer solo usan 2 bytes de la pila (la dirección de retorno) y meten su propia pila en la pantalla para evitar este problema.
Lo que te decía, el original sólo usaba dos bytes de pantalla y pillaba el stack de programa


- No sé hasta cuántos juegos necesitan preservar R... aunque he visto unas cuantas rutinas decodificadoras para las que es imprescindible. En caso de que decidas complicarte la vida y preservarlo, hay que tocar ese JP PO (ya que R avanzará más o menos dependiendo de si se salta o no).
Probablemente aquellos que podían ejecutar mantransfe v2 (que no tocaban las interrupciones) seguramente no usaban el registro R para nada ;)
Podría mejorarlo y hacer que lo guardase, pero creo que los únicos usos del registro R son para generar números aleatorios o para proteger rutinas de carga

- Si IM x va cargada a martillazos (en una posición fija), lo mismo te quitar el call y meter directamente la instrucción ahí.
Eso no lo entiendo

La rutina que usas es muy cortita... creo que incluso se podría parchear una ROM de 48k y ponerla como rutina de NMI (al estilo de La Máquina Alucinante). Así tendrías tu propio transfer integrado en un Spectrum real o emulado.
Eso molaria!! :)

Gracias por tus comentarios
Saludos
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Mié Abr 25, 2018 4:54 pm

Vale, va por adelantado que el conocimiento que tengo de este tema es por espiar cómo funcionan las rutinas de diferentes transfer y que no tengo conocimientos muy profundos de las interioridades de un Z80.
chernandezba escribió:Si, esa instrucción la establezco desde ZEsarUX. Desde software (desde z80) no se puede saber en que modo IM está la cpu. Pero lógicamente como la versión original de mantransfe funcionaba en modo im2 pues no hay necesidad de saberlo. En esta versión que usa ZEsarUX se puede usar tanto en juegos que usen im2 o no.
En la rutina que restaura el estado del equipo, usas un call que llama a donde está el im. Esta construcción (call/im/ret) ocupa 6 bytes, lo que sugería es colocar directamente la instrucción im y ahorrarte el call/ret.

En cuanto a lo de la detección de IM1/2... la variante más sencilla que he visto es la del Pokeador Automático (dicho sea de paso, también es la más propensa a fallar): si I=63 pone IM1, y en cualquier otro caso IM2. Una más compleja es la que vió mcleod espiando el código de la ROM del Phoenix.
chernandezba escribió:Lo que te decía, el original sólo usaba dos bytes de pantalla y pillaba el stack de programa
La mayoría de los transfers (excepción: el Specmate, que curiosamente también es el único transfer aparte de Multiface que ha sido emulado alguna vez) no confían en la pila del programa. Como te comentaba, si la pila va un poco justa (es increíble lo que se metía en 48k a base de apretar) al meter tanto byte te arriesgas a sobreescribir lo que haya justo debajo de la pila y que el programa luego no funcione (o peor, aparente funcionar bien hasta mucho rato después).

Lo que hacían era guardar SP (como haces tú) y luego poner SP en algún lugar de la pantalla para meter todos los registros ahí. Eso produce una línea más de corrupción, pero respetas el programa al máximo ya que solo le robas 2 bytes (los que no te queda otro remedio, porque al hacer la NMI el micro mete la dirección de retorno en el stack).

Como curiosidad, buscando información sobre el formato .sna, encontré una página donde decía que algunos juegos fallaban por esos dos bytes... imagino que es un caso muy extremo y que hay que tener muy mala leche para pulsar el botón de NMI justo cuando está al final de la pila.
chernandezba escribió:Eso no lo entiendo
Cuando digo que algo está metido a martillazos es porque va en una dirección fija "porque yo lo valgo" o un valor específico que elegimos para que las cosas funcionen. En este caso, me refiero a que la instrucción es fija (y va en una dirección fija) en contraposición a otras rutinas que según una cierta condición establecen IM en un valor u otro. El resto está explicado un poco más arriba.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Vie Abr 27, 2018 3:52 pm

Hasta que consiga un alojamiento, dejo aquí la nueva versión de sna2transtape.

Por fin funcionan todos los switches más o menos como deben. La introducción de datos al usar -n no es del todo precisa, así que siempre se informa del nombre que se le va a poner al programa.

También hay algún cambio cosmético, pero poco más. Los fuentes, cuando apañe una página web.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Sab Dic 15, 2018 10:26 am

Después de mucho tiempo, he caído en la cuenta que tengo un blog semiabandonado. He subido una entrada al blog con toda la información y descargas del sna2transtape.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por chernandezba » Lun Dic 17, 2018 2:28 pm

zup escribió:Después de mucho tiempo, he caído en la cuenta que tengo un blog semiabandonado. He subido una entrada al blog con toda la información y descargas del sna2transtape.
Así resumido, mejor :) Gracias!
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Dom Jun 07, 2020 7:10 pm

Actualizo el programa a la versión 0.47.

Nuevas características:
- Nueva opción sin sentido: -s garantiza que el tap sea 100% exacto a lo que haría el transtape. Es exactamente igual a no incluir las opciones -b y -f... de hecho, al incluir -s se deshabilitan estas dos opciones.
- El código fuente ya no escupe warnings al ser compilado.
- Me he cepillado un bug futuro.

Lo que me queda por hacer:
- Pulir un poquito más el código para que no parezca chapucero a simple vista, pero siga igual de cutre que siempre.
- Intentar ampliarlo a 128k (algo que no hacía el transtape).
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Lun Jun 15, 2020 8:08 am

He ido actualizando tan rápido que ni he puesto los mensajes... ahora el programa va por la versión 1.20.

Las dos grandes novedades son:
- Ya convierte ficheros de 128k.
- En los ficheros de 128k, se detecta el primer y último byte usado de cada página para reducir el tamaño de los tap (y tiempo de carga). Se ha añadido el switch -t para desactivar este comportamiento (y crear copias que cargan explícitamente toda la memoria).

Este "recorte" ha traído a la luz un pequeño detalle de los Spectrum 128k... no inicializan toda la RAM a 0. O más bien la inicializan, pero luego la usan. En toda la gama de 128k siempre se usa de la página 7, por lo que el snapshot siempre tiene bytes usados en la RAM 7. En el caso de los +2A y +3 el uso de la RAM 7 se amplía y además se usan las RAM 1, 3, 4 y 6 para el RAMDisk.

¿Resultado? Un Snapshot de Fairlight sacado en un +2 tarda en cargar 8m 06s, mientras que el mismo snapshot sacado en un +3 se va a los 12m 19s (más o menos lo que tardaría en cargar una copia completa de la RAM). Por contra, un snapshot sacado de una máquina en la que previamente se ha puesto a cero (casi) toda la RAM tarda 7m 45s.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Sab Jun 27, 2020 8:02 pm

Vale, creo que esta va a ser una de las últimas actualizaciones al programa. Las novedades son:
- Bugfix para las versiones 1.02 y 1.20... no las había testeado lo suficiente. Se habían escapado un bug que causaba que los ficheros de 128k solo se convirtieran al utilizar -v, y otro que hacía que las cargas tuvieran una alta probabilidad de fallar en +2A/+3.
- Nueva versión 1.24. En esta versión se ha añadido un algoritmo de compresión RLE, lo que acorta tiempos de carga (no es demasiado espectacular, pero resuelve los tiempos de carga con snapshots de +3). Esto está controlado con el switch -t. Si lo ponemos, se hace un fichero .tap XXL con toda la memoria; si no lo ponemos el programa aplicará los algoritmos de recorte y compresión.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Proyecto tontuno... conversor de snapshots a transfer

Mensaje por zup » Jue Jul 23, 2020 4:43 pm

Creo que ya este programa ya está terminado (salvo informes de bugs), así que he subido la versión 1.28. Las novedades son:
- Se sustituye la compresión RLE de 16 bits por RLE de 8 bits. Los ficheros se comprimen algo menos, pero la rutina es mucho más clara.
- Se añade sna2phoenix, el equivalente usando el formato del Phoenix (corrupción de pantalla más discreta).
- Se añade sp2transtape, homenaje al emulador de Pedro Gimeno.
- Se añade sna2zx7, que utiliza la rutina de arranque de Phoenix (misma corrupción) pero comprime casi toda la RAM usando el algoritmo zx7.
- Se han vuelto a "barajar" las funciones y repartirlas de una manera más racional (¿seguro?) en los ficheros .h para evitar duplicidades de código.

Dos cosas a destacar:
- El cargador original del Phoenix no creo que sea 100% compatible con todos los dispositivos (especialmente con el DivIDE), así que se usa un cargador alternativo y compatible. Si se usa sna2phoenix con el switch -s, se generará un .tap idéntico al de Phoenix... incluyendo el problemático cargador original.
- Mientras programaba sna2zx7 tuve que consultar con su autor acerca de un comportamiento no esperado. Si comprime datos "revueltos", la compresión es muy rápida; si comprime datos con muchas repeticiones (por ejemplo, esas páginas llenas de 0xE5 del +3), la compresión es asquerosamente lenta. Al parecer, es un comportamiento normal... menos mal que los tap se generan solo una vez.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 7 invitados