Pruebas en Dragon

Avatar de Usuario
Chema
Mensajes: 2664
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 3190 veces
Agradecimiento recibido: 926 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor Chema » 20 Feb 2015 11:33

Último mensaje de la página anterior:

Esto ya es otra cosa... Habría que ver el rendimiento del descompresor, pero si va medianamente bien la cosa tiene buena pinta.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 13:51

como en Dragón podemos reservar dos áreas de 6144 bytes para gráficos, he cargado la imagen comprimida en la segunda área
y le doy como destino a la rutina descompresora el final de la primera área, pero sigue sin hacer nada bueno.
Simplemente se dibuja una linea muy corta y se cuelga!

Subo el VDK de trabajo y el zip con el Exomizer2 entero.
Por si alguien puede echarle una ojeada aunque solo sea al manual del Exomizer ... igual he hecho mal la compresión
puse: exomizer raw Hob01.pm4
y me creó un fichero a.out que renombré a Hob01.exo
Luego le añadí la cabecera estandar de Dragon y lo copié en el VDK

Animo, a ver si alguien le echa luz a este tunel -drinks

saludos
pere
Adjuntos
25 - The Hobbit - Pruebas de Exomizer2.zip
El VDK de pruebas para XRoar
(5.51 KiB) Descargado 130 veces
Exomizer2.zip
(642.55 KiB) Descargado 135 veces

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor jltursan » 20 Feb 2015 16:38

¿Podrías adjuntar el código que estás empleando?. El binario Hob25.pm4 ya lo tengo yo por aquí, a ver si con el toolchain que me monté puedo hacer pruebas yo también cómodamente (teniendo en cuenta que yo de 6809 poco).

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 18:14

Hola José Luis,

te adjunto el fuente ensamblador de 6809 original de Exomizer con unas pocas sentencias delante para poner datos iniciales
También adjunto el programa Basic que ejecuto, con muchas paradas para ir viendo los pasos

No quiero que sea la solución final, pero de momento reservo 8 páginas para gráficos (dos pantallas)
La primera (páginas 1-4) debería recibir la imagen descomprimida
La segunda (páginas 5-8) es donde se carga la pantalla comprimida

Como parece que el descompresor va en orden inverso, la posición DESTINO debe ser:
Inicio de pantalla + Longitud fichero no comprimido - 1 = $C00 + 4032-1 = $1BBF. Este valor se carga en Y
Final del fichero comprimido:
En Dragon con discos (en XRoar también), $652-653 contienen la dirección de inicio del fichero recién cargado
mientras que $654-655 tienen la longitud total del fichero
Por ello hago load D con 652, le sumo 654 lo paso a U y le resto 1
A continuación se ejecuta la rutina tal como la pensaron sus desarrolladores, solo le he añadido OR #$50 para deshabilitar interrupciones (ya que modifican la direct page DP)
y al final los habilito con ANDCC #$AF

Cualquier tema que te surja,no dudes en comentarlo aquí mismo ... estoy liado con otros temas, pero mantengo un ojo al foro!

saludos
pere


saludos
pere
Adjuntos
DEMOEXO2.BAS.ZIP
La demo
(398 Bytes) Descargado 142 veces
exo2test.asm.zip
el fuente retocado
(1.71 KiB) Descargado 126 veces

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 18:48

a título de curiosidad, he probado este comando
exomizer raw -d Hob01.exo (nombre que yo le puse al comprimido)
y me ha generado un fichero a.out de 4032 bytes idéntico al original Hob01.pm4
O sea confirmo que el fichero comprimido es correcto!!
Ahora necesitamos saber si el fuente que se adjunta l ZIP de exomizer para 6809 es de la misma versión que el ejecutable de windows/dos actual o es mas antiguo e incompatible !?

saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 22:17

ya funciona!!!
dentro de un rato subo un VDK de demo

saludos
pere

EDITO:
Había algunos gazapos ...
1) el descompresor va de final a princpio, pero al comprimir sin opciones lo hace de principio a fin o sea incompatible
2) los punteros hay que informarlos antes de entrar en la rutina o luego Y no está con el valor adecuado en el stack

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 22:55

Hola de nuevo,
Os subo un VDK con los ficheros necesarios para ver como trabaja este descompresor.
Es mucho mas lento que el de Sixxie, pero comprime mucho mas los ficheros.

Veréis que hay dos ficheros Basic, uno DEMOSLOW y otro DEMOFAST
Los nombres no pretenden indicar velocidad de descompresión, el SLOW tiene muchos mas pasos intermedios y requiere que se pulse C mas veces
El otro es mas directo.
Ambos trabajan con PCLEAR8 (dos imagenes. La comprimida se carga en la segunda (pags 5-8) y se descomprime en la 1-4)

Obviamente esto habrá de trabajar directamente en la 1-4 o no tendríamos espacio para el programa. Ya duele lo suyo que el programa mas el área de datos
que requiere ocupen 356 bytes ... el de Sixxie solo necesitaba 52 bytes!

Se aceptan comentarios - propuestas -thumbup

saludos
pere

Pd. Para ser honestos, me he rallado y he enviado un correo al autor del descompresor, Magnus Lind que muy amablemente ha contestado muy rápido
indicándome el detalle de forwards - backwards.
A mi parecer no estaba muy claro en el manual, pero ahora, a toro pasado, parece lógico que sea así

Otro encarguillo, comprimir todas las imágenes con este Exomizer2 y prepararlos en un disco tras haber cambiado el uso de memoria gráfica ...

@José Luis
ya puedes empezar a buscar mas pantallas (nos caben el doble o sea unas 22 mas, casi nada!)
Adjuntos
25 - Hobbit_11 - Pruebas de Exomizer2.zip
(7.54 KiB) Descargado 127 veces

Avatar de Usuario
ron
Mensajes: 21855
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 3862 veces
Agradecimiento recibido: 4752 veces

Re: Pruebas en Dragon

Mensajepor ron » 20 Feb 2015 23:09

pere... ¿ aceptas una ovacion ?

Que grande !!!

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 23:49

Hola Rodrigo,

esto es peor que una excursión por alta montaña, hay que ir sorteando obstáculos permanentemente.
Como solo disponemos de una pantalla para gráficos (6144 bytes) de los cuales la imagen ocupa los 4032 bytes de la parte superior, hay que cargar las pantallas comprimidas arriba del todo
y dejar que el descompresor vaya leyendo desde el final de dicho empaquetado hacia atrás y copiando también al final de los 4032 bytes y hacia arriba.
El problema es que este algoritmo, a veces, hace mucho trozo de una tirada (de ahí los 156 bytes de tablas) y sucede, como en este Hob01.pm4 que la primera fila de la imagen, al procesarla al final del todo, la está grabando mientras la va leyendo, resultado ... espantoso, el descompresor no encuentra el final (inicio) y sigue como un loco de forma que el sistema queda colgado como un "Güindows" cualquiera.

De momento he encontrado la solución de replicar la imagen 32 bytes mas abajo con lo cual es necesario, ahora en Basic limpiar los 32 bytes de arriba, pero en el programa habría que hacer un scroll hacia arriba de toda la imagen una fila de bytes. No es grave, pero serán unos pocos bytes mas de código a añadir a la rutina ya de por si bastante grande.
NO vendrá de unos 20 octetos mas o menos ...
A ver cual será la próxima sorpresa.Lo que está claro es que hay que probar con TODAS las imágenes, no sea que alguna requiera que se la desplace mas de una fila para evitar que se pisen lecturas - escrituras al final del proceso de descompresión, o sea arriba del todo.

saludos
pere


Por cierto, me vale con los ánimos que me dais

BlackHole
Mensajes: 1669
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 29 veces
Agradecimiento recibido: 523 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 21 Feb 2015 04:21

No conozco el mapa de memoria del Dragón, pero en general para cualquier ordenador, siempre que necesitemos descomprimir datos sobre el mismo área de memoria, hay que colocar los datos en el extremo contrario al sentido de descompresión. Si descomprimimos hacia atrás, hay que colocar los datos abajo del todo, apuntar el origen de la descompresión al final de los datos, apuntar el destino de la descompresión al final de la zona de memoria, e ir decrementando (gráfico de arriba). Si descomprimimos hacia adelante, hay que colocar los datos arriba del todo, apuntar el origen de la descompresión al inicio de los datos, apuntar el destino de la descompresión al inicio de la zona de memoria, e ir incrementando (gráfico de abajo):

Imagen

En el proceso siempre hay un momento en el que se superponen los datos descomprimidos a los comprimidos, corrompiendo la memoria a partir de ese punto, con la posibilidad de sobreescribir código y colgar el equipo, como te ha pasado. En el caso de aPLib, donde el algoritmo de descompresión está perfectamente documentado en C, yo me hice un programa que calculaba el "offset" (la distancia entre cada byte comprimido y su posición descomprimida) necesario para salvar, y casi siempre apenas eran 1 a 4 bytes... salvo que comprimamos datos aleatorios o previamente comprimidos.

Pero sin embargo el propio programa Exomizer, si os fijáis, ya nos está avisando de ese "safety offset" con un mensaje. Son esos los datos que tendremos que mover fuera del área del "rectángulo". En todos los casos de las 22 imágenes, Exomizer nos dice que el margen de seguridad son 2 bytes. Entonces, o movéis todos los datos a descomprimir 2 posiciones fuera del rectángulo, o comprimís los últimos 4030 bytes de cada imagen dejando los 2 primeros previamente en la pila o alguna parte segura... esto último lo hago yo en Spectrum mucho en mis programas (y aquí ando revelando mis técnicas, hehehe).

Por supuesto, todo esto sucede cuando necesitamos hacer una descompresión "in place", es decir, en el mismo área de destino. Si podemos reservar otra zona de memoria, no tenemos ese problema. En la época en la que yo estaba en la escena de Commodore 64, otra cosa que se hacía mucho en los juegos multicarga, era usar nuestras propias rutinas de acceso al disco, de tal forma que leíamos los bytes del fichero de uno en uno y se los pasábamos en tiempo real al descompresor que dejaba los datos descomprimidos en memoria sin tener que utilizar buffers intermedios.

Yo llevo haciendo esto 25 años y lo veo claro, pero no sé si se entiende bien mi explicación.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 21 Feb 2015 09:56

Buenos días,

muchas gracias por esta clarísima explicación ...
Está claro que hay un momento en que se pisan, pero como no me fijé en este detalle al comprimir las pantallas, por facilidad tomé un margen de seguridad simple de
implementar: 1 fila de 32 bytes (es mucho por lo que cuentas)
Estoy convencido de que bastará con moverlo cuatro bytes. Y además ni se notaría.
De momento lo tengo hecho de tal forma que al finalizar la descompresión, actúa una rutina de scroll hacia arriba (1 linea) y además borra la linea inferior (desplazada hacia
abajo para salvar el problema)

Estoy pensando en NO hacer el scroll y simplemente borrar la fila superior que es donde se cargaron los datos comprimidos. Será mas rápido y requiere menos código/espacio del que
no vamos sobrados.
La opción que se desprende de tu explicación podría ser cargar el fichero comprimido desplazado, por ejemplo, cuatro bytes ANTES del principio, por si las moscas
Hay que ver que podría encontrarse en esta zona, en caso de conflicto, me vale reconstruirlo 32 bytes mas abajo (ha de ser multiplo de 32)

Espero poder subir un VDK con las dos/tres variantes, con scroll una, la otra solo limpiando y la posible tercera invadiendo 4 bytes previos de la pantalla real.
Veremos para que da un finde algo apretado de agenda -507

saludos
pere

BlackHole
Mensajes: 1669
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 29 veces
Agradecimiento recibido: 523 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 21 Feb 2015 14:08

En Exomizer no tienes que adivinar cuál es el margen de seguridad. Te lo dice el propio programa al comprimir:

exomizer.exe raw bn_Hob01.pm4
[blablabla]
Length of crunched data: 2127 bytes.
Literal sequences are not used and the safety offset is 2.

En los 22 ficheros, el margen es de 2 bytes, así que solo necesitas desplazar 2 bytes. Ignoro si eso supone un problema, ya que como dije desconozco el mapa de memoria y no sé si afecta a áreas útiles. No entiendo por qué dices "pantalla real". ¿Entonces descomprimes en una pantalla alternativa que no está a la vista? Perdona si hago una pregunta estúpida.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 21 Feb 2015 15:26

@Blackhole

pues si es un problema, de momento falla aleatoriamente cuando trato de utilizar 2-4-8-16-32 bytes anteriores al inicio de pantalla.
Teóricamente son parte del cuarto de los 4 buffers de lectura del S.O. de disco
Parando el programa tras la carga (desplazada hacia atrás) de la imagen comprimida y mirando el contenido de los bytes anteriores al inico de pantalla
puedo garantizar que ninguno ha sufrido cambios.
Sin embargo al ejecutar la rutina, esta descomprime desde abajo perfectamente bien un 80-90% y luego o bien se queda frito y puede llenar la pantalla de basura
o bien se queda parado dejando la parte superior sin descomprimir pero devolviendo control al Basic, en este caso, si miro el contenido de los bytes anteriores
al inicio garantizo que han sido modificados ... pero no se `por parte de quien
Hasta ahora bloqueaba las interrupciones antes de descomprimir. Como última prueba no lo haré y a ver que pasa.
Curiosamente, en una ocasión he cargado la pantalla 256 bytes antes (un sector entero) y me ha funcionado correctamente, pero al intentarlo varias veces
el resultado era aleatorio, funcionaba o fallaba según Dios sabe qué!

No me preocupa mucho ya que montar la pantalla una fila mas abajo (desperdiciando los 32 bytes de la fila superior) prácticamente no se nota y creo que además no afectará
para nada al texto que pueda haber abajo. Encima la pantalla se ve poco rato, ya que al empezar a soltar parrafadas el programa, hace scroll a cada linea, no creo que
valga la pena mas esfuerzos para casi nada de nada.

Muchísimas gracias por las ideas y por el tiempo dedicado -thumbup
Se agradece un montón, como dicen algunos yanquis ... Thanks a bunch!

saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 21 Feb 2015 16:23

Bueno,
creo que no voy a dedicarle mas tiempo a este tema ... vosotros decidís que variante os gusta mas.
Adjunto un VDK lleno de basurita
El programa descompresor está en tres versiones:
a) EXO2A.BIN, éste ocupa 385 bytes, carga la imagen comprimida en $C00 y regenera en $C20 (para dar margen de seguridad), al fializar hace scroll arriba una fila y borra la sobrante de abajo, buf!
b) EXO2B.BIN, éste ocupa 373 bytes, carga en $C00, regenera en $C20 pero NO hace scroll y borra la primera fila (restos del fichero comprimido). La imagen queda desplazada una fila hacia ABAJO!
c) EXO2C.BIN, éste ocupa 356 bytes, carga en $B00 (256 bytes antes, viva la seguridad y el riesgo!), regenera en $C00 y regresa ... si no casca, claro ;-)

Para hacer pruebas de cada uno de ellos hay dos versiones de programa Basic, el lento, acabado en SL que pide mas veces que pusemos la tecla C para continuar pero así da tiempo a ver la imagen comprimida antes de que se recomponga
El otro, rápido, acabado en FS solo espera una C para cargar y descomprimir.
En ambas versiones, al final, pulsando C regresamos al Basic
Los nombres son crípticos de narices:
DEXO2ASL.BAS
DEXO2AFS.BAS para la versión a)
DEXO2BSL y DEXO2BFS para la b)
DEXO2CSL para la c), para esta no he hecho rápida porqué no tengo claro si vale la pena usar esta variante ...

Debo destacar que la versión c) es algo aleatoria, suele funcionar pero a veces me ha cascado vilmente ...
Tened en cuenta que el área anterior a la pantalla pertenece al sistema de disco (bufer de lectura), así que según la versión de DOS que se utilice puede darnos una alegría o una decepción.
Si cargáis DEMO2CSL.BAS y editáis la línea 120:
120 LOAD"HOB01EXO.BIN",&HB00 Podréis experimentar lo que pasa cambiando la dirección de carga. Ahora está justo 256 bytes antes del inicio de pantalla, que es $C00
podéis cambiar el final por lo siguiente ,&HC00-x
Y en x ponéis el valor que os parezca. He probado con 2-4-8-16-32-128 y con otros valores intermedios
La inmensa mayoría (por encima de 8 ó 16) no acaban la pantalla entera, pero vuelven al Basic. Los casos con x igual o menor de 8 suelen colgarsse sistemáticamente

No me parece lógico que suceda ya que deshabilito las interrupciones antes de arrancar la rutina de descompresión, pero no pienso dedicarle mas tiempo.
A mi la versión B me parece la mas económica (nos ahorramos el tiempo y los bytes del scroll) y una linea ni se notará!

Espero vuestras opiniones

saludos
pere
Adjuntos
25 - Hobbit_11 - Pruebas de Exomizer2 PCLEAR4.zip
3 opciones para descomprimir
(8.39 KiB) Descargado 117 veces

Avatar de Usuario
ron
Mensajes: 21855
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 3862 veces
Agradecimiento recibido: 4752 veces

Re: Pruebas en Dragon

Mensajepor ron » 21 Feb 2015 18:42

DEXO2CSL se cuaja. En cambio la version A y B funcionan sin problemas AFS y BFS.
Hay una ( creo que la B ) en la que no se produce el scroll y en la A si parece que lo hace.

La DEXOASL a mi opinión es la que mejor lo hace. Pero eso es mi opinión y mientras pinte y lo haga sin complicarte mucho la vida, asunto arreglado.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 21 Feb 2015 19:34

Hola Rodrigo,
La A es la que hace el scroll para arriba, de todas formas, ya ha machacado la linea superior de la primera fila de texto al recomponerse la imagen
La B no hace el scroll, ya lo hará el programa conforme vaya escribiendo

Estoy finalizando el VDK con las 22 pantallas comprimidas, trataré de hacer que se pueda elegir el compresor al vuelo

saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 21 Feb 2015 20:03

Bien,

este es el VDK de demo para las 22 pantallas comprimidas con Exomizer2 ... hay que ver la cantidad de espacio libre que nos queda en el disco, qué barbaridad!
Viene con los dos métodos de descompresión que NO cascan ... el que hace scroll y el que no lo hace, así podréis comparar.
He añadido una opción al menú inicial para poder cambiar sobre la marcha de rutina de descompresión.
Como no he querido tener las dos al mismo tiempo en memoria, las cargo al vuelo, son cortas, al finalizar la carga suelta un pitido de aviso ...
El efecto se aplica de inmediato, es decir, se carga la rutina, suena el pitido, se borra la pantalla y se carga y descomprime con el otro método la misma imagen que veíamos
Todo sea por facilitar comparaciones ...
por cierto basta con hacer
RUN"DEMO

Ya daréis vuestra opinión al respecto

saludos y buen fin de semana
pere
Adjuntos
25 - Pantallas Hobbit Exomizer2.zip
22 pantallas - 2 métodos de descompresión
(47.13 KiB) Descargado 125 veces


Volver a “Proyecto The Hobbit 6809 por pser1”

¿Quién está conectado?

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