Karoshi MSX Community
26 de Junio de 2017, 07:26:07 am *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Calendario Ingresar Registrarse  
Páginas: [1] 2
  Imprimir  
Autor Tema: Exomizer 2, rutinas descompresoras actualizadas  (Leído 5107 veces)
0 Usuarios y 1 Visitante están viendo este tema.
Metalbrain
Karoshi Fan
**
Mensajes: 92


Z80jutsushi


Ver Perfil
« : 17 de Enero de 2012, 06:56:32 pm »

Allá por diciembre del 2007, cuando convertí el descompresor en crudo de Exomizer al Z80, creé un hilo en msx.org, pero no aquí, (entre otras cosas todavía no estaba apuntado al foro), así que aprovechando que hay novedades, pues lo creo ahora:

Señoras y señores, con ustedes el método de compresión que vence con claridad tanto al de aPLib como al de pucrunch: exomizer 2.

http://hem.bredband.net/magli143/exo/

Como no había descompresor para Z80, lo porté yo, y además hice un optimizador que coge la salida del exomizer, le quita 2 bits inútiles y le reordena los bits para que se puedan leer un poco más rápido con el Z80. Hace escasos días Antonio Villena ha optimizado los descompresores de forma que ahora son más rápidos, y de paso les ha recortado unos cuantos bytes.

Los tamaños de los descompresores varían entre 163-187 bytes. La rutina descompresora necesita una tabla de 156 bytes, que puede ser desechada tras la descompresión, así que si la ponemos en un buffer no debería suponer ningún gasto extra. De registros alternativos solo utiliza el AF'.

http://www.speccy.org/metalbrain/exo_v4.zip

En la carpeta /normal están las versiones que funcionan directamente con la salida que genera exomizer al hacer:

exomizer raw -o salida entrada

En /optimized están las que funcionan con la salida optimizada, la cual se genera haciendo:

exomizer raw -o temporal entrada
exoopt temporal salida

exoopt es el optimizador, el ejecutable Windows está presente en optimized/bin y su código fuente para otros sistemas en optimized/src

Las rutinas _simple necesitan que la tabla esté alineada a un múltiplo de 256, y no soportan cadenas de literales, que suele ser raro que aparezcan y además se pueden desactivar con la opción -c de exomizer.
En línea
j4mk3
Karoshi Maniac
****
Mensajes: 368


MSx Powa!


Ver Perfil WWW Email
« Respuesta #1 : 17 de Enero de 2012, 11:59:44 pm »

Lo estudiaremos...hmm hmmm Smiley
Pero pasado el jueves 26...que estoy de examenes de 日本語 Smiley
En línea

---  G Fan  ---  Galious & Gradius  & G Boys   ---
--- Play HANS' ADVENTURE & STAN, THE DREAMER ---
Mortimer
Karoshi Lover
***
Mensajes: 216


Ver Perfil WWW
« Respuesta #2 : 18 de Enero de 2012, 02:32:41 pm »

Muy interesante, precisamente hace nada estuve probando varios descompresores que estaban listos para utilizar en MSX, y elegí el Pletter, por el menor tamaño del resultado, que en algunos casos podía ser un 60% más pequeño que el bitbuster que utilizaba hasta ahora, y sobre todo por la mayor velocidad de descompresión. (Quiero descomprimir un puñado de bytes frame si, frame no)

Lo he pasado ahora por la misma batería de archivos con los que hice las pruebas, y así en general he visto que Exomizer comprime un poco más los archivos grandes, y un poco menos los pequeños. (También es mucho más lento comprimiendo, aunque eso no me preocupa lo más mínimo). Mediré los resultados de tiempos de descompresión y ya os contaré.

Por cierto, ¿Podrías comentar aunque sea a grandes rasgos que cambios haces en el formato original para optimizarlo para Z80? He mirado el código fuente pero no me he enterado de mucho...

En línea
Metalbrain
Karoshi Fan
**
Mensajes: 92


Z80jutsushi


Ver Perfil
« Respuesta #3 : 18 de Enero de 2012, 03:19:33 pm »

Por cierto, ¿Podrías comentar aunque sea a grandes rasgos que cambios haces en el formato original para optimizarlo para Z80? He mirado el código fuente pero no me he enterado de mucho...

En el formato original se leen los bits de derecha a izquierda (se empieza por el bit 0, luego el 1, luego el 2... se va rotando hacia la derecha). Yo le cambio la orientación de esa lectura para que se lean de izquierda a derecha (primero el 7, luego el 6, luego el 5...). De esta forma, se pueden ir sacando los bits haciendo ADD A,A (que ocupa 1 byte y tarda 4 estados) en lugar de usar SRL A (que ocupa 2 bytes y tarda 8 estados).

Aparte me cargo dos bits redundantes que son el bit marcador del primer byte (en el formato original, el primer byte tiene 7 bits de datos y el bit marcador que señala el final de los datos), y el primer bit (que tiene un valor fijo puesto que al principio no existe historia, y a la fuerza tiene que señalar un byte literal).
En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


Ver Perfil WWW
« Respuesta #4 : 19 de Enero de 2012, 12:25:18 am »

Gracias por la info  Wink, Pues os cuento, ya he podido hacer una prueba de velocidad con archivos optimizados para la rutina de deexo_simple, por ahora sólo descomprimir 192 bytes. La velocidad la he medido a ojo contando las líneas del cambio de color del borde, los resultados son:

  • Bitbuster: Tamaño comprimido 107 bytes, tiempo descompresión 90 líneas
  • Pletter: Tamaño: 105 bytes, tiempo 60 líneas
  • Exo: Tamaño: 116 bytes, tiempo, más de una pantalla completa con su retrazado... Demasiada diferencia, no sé si habré hecho algo mal  Huh

Probaré con tamaños más grandes a ver como se porta.

En línea
SapphiRe_MSX
Visitante
« Respuesta #5 : 19 de Enero de 2012, 12:37:38 pm »

Quiero descomprimir un puñado de bytes frame si, frame no

Olvídalo. Para eso, guarda los datos descomprimidos o bien descomprime todo a RAM y listos. Descomprimir mientras juegas es inviable.
En línea
Iggy Rock
Visitante
« Respuesta #6 : 19 de Enero de 2012, 02:42:52 pm »

@offtopic:Bueno, descomprmir RLE es perrfectamente viable, mejor incluso directemente en VRAM y mas rápido que el volcado directo los datos sin comprimir. Puedes considerar esta opcion, aunque la compresion no sea muy buena, se puede ganar bastante espacio.
« Última modificación: 19 de Enero de 2012, 02:47:11 pm por Iggy Rock » En línea
SapphiRe_MSX
Visitante
« Respuesta #7 : 19 de Enero de 2012, 02:48:43 pm »

@offtopic:Bueno, descomprmir RLE es perrfectamente viable, mejor incluso directemente en VRAM y mas rápido que el volcado directo los datos sin comprimir.

¿Descomprimir RLE directamente a VRAM es más rápido que el volcado directo de los datos sin comprimir? No se, aquí hay algo que no me cuadra...  Roll Eyes
En línea
Iggy Rock
Visitante
« Respuesta #8 : 19 de Enero de 2012, 05:24:00 pm »


Dime que no y empezamos un debate Grin
En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


Ver Perfil WWW
« Respuesta #9 : 19 de Enero de 2012, 06:03:12 pm »

Olvídalo. Para eso, guarda los datos descomprimidos o bien descomprime todo a RAM y listos. Descomprimir mientras juegas es inviable.

Eres el mejor dándo ánimos  Cheesy. Bueno, todo dependerá de los bytes de los que hablemos, y de los ciclos que ocupe la descompresión y los que necesites por frame... por ahora me va bien, si luego me quedo corto pues tendré que ponerlo descomprimido que yo también creía que es lo más rápido.

Dime que no y empezamos un debate Grin

Si no te contesta él lo hago yo, pero abrimos otro hilo!
En línea
SapphiRe_MSX
Visitante
« Respuesta #10 : 19 de Enero de 2012, 10:42:05 pm »

Código:
outi
outi
outi
...
En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


Ver Perfil WWW
« Respuesta #11 : 19 de Enero de 2012, 10:53:09 pm »

Se me ocurre lo siguiente:

Si no me equivoco con los M1 incluídos OUTI necesita 18 ciclos, y OUT (n),A sólo 12

Si los datos vienen en RLE y hay suficientes repeticiones lo suficientemente largas, guardamos el dato en A compensaría tener unos OUT (n),A desenrollados si la sección del código que decide dónde saltar es eficiente, supongo que lo mejor sería usar JP (HL).
En línea
Iggy Rock
Visitante
« Respuesta #12 : 20 de Enero de 2012, 12:34:20 am »

Y a mayor compresión...
En línea
aorante
Karoshi Maniac
****
Mensajes: 445


nuTella Power!


Ver Perfil WWW Email
« Respuesta #13 : 20 de Enero de 2012, 03:15:34 pm »

pero la descompresión directa (RLE) a VRAM no le afectaria el problema del cuello de botella del VDP de los MSX1? Huh
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
SapphiRe_MSX
Visitante
« Respuesta #14 : 20 de Enero de 2012, 03:44:56 pm »

Si no me equivoco con los M1 incluídos OUTI necesita 18 ciclos, y OUT (n),A sólo 12

Si los datos vienen en RLE y hay suficientes repeticiones lo suficientemente largas, guardamos el dato en A compensaría tener unos OUT (n),A desenrollados si la sección del código que decide dónde saltar es eficiente, supongo que lo mejor sería usar JP (HL).

Calcula a partir de qué tamaño sale más rentable descomprimir datos de esta forma que volcar directamente. Debes incluir en el cálculo todo el tema de descomprimir, calcular el salto, saltar...

Aparte de eso, OUT (n),A tiene un problema: el puerto n no tiene por qué ser el mismo en todos los MSX. Hay que leerlo de la BIOS, lo cual significa que los OUTs deberían estar en RAM. Lo cual también es lógico, porque imagina tener que guartar todos ellos en ROM: ¡la rutina de descompresión ocuparía bastante sitio!
En línea
Páginas: [1] 2
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!