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

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

Notapor zup el 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: 624
Registrado: Vie Ago 15, 2008 2:43 pm

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

Notapor zup el 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...
zup
Freddy Hardest
 
Mensajes: 624
Registrado: Vie Ago 15, 2008 2:43 pm

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

Notapor kounch el 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.
kounch
rst 0
 
Mensajes: 6
Registrado: Mar Dic 05, 2017 9:02 am

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

Notapor zup el 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: 624
Registrado: Vie Ago 15, 2008 2:43 pm

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

Notapor zup el 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...
zup
Freddy Hardest
 
Mensajes: 624
Registrado: Vie Ago 15, 2008 2:43 pm

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

Notapor zx81 el 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
zx81
Freddy Hardest
 
Mensajes: 571
Registrado: Vie Dic 28, 2007 3:14 pm
Ubicación: Valencia

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

Notapor chernandezba el Mie 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://sourceforge.net/projects/zesarux/
Avatar de Usuario
chernandezba
Sabreman
 
Mensajes: 365
Registrado: Mie Oct 17, 2007 5:26 pm

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

Notapor zup el Mie 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: 624
Registrado: Vie Ago 15, 2008 2:43 pm

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

Notapor zup el 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: 624
Registrado: Vie Ago 15, 2008 2:43 pm

Previo

Volver a Emulación y preservación

¿Quién está conectado?

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