Karoshi MSX Community

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.

Lo estudiaremos...hmm hmmm :)
Pero pasado el jueves 26...que estoy de examenes de 日本語 :)

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 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).

Gracias por la info  ;), 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  ???

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

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

@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.

¿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...  ::)

Dime que no y empezamos un debate ;D

Eres el mejor dándo ánimos  :D. 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.


Si no te contesta él lo hago yo, pero abrimos otro hilo!

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).

Y a mayor compresión...

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

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!

Ops!   :o

Metí la pata al volver a meter los comentarios en el código nuevo, incluyendo en la rutina normal (no simple) una línea de la versión antigua que jode toda la descompresión. Ya está corregido, os lo podeis volver a bajar en el mismo enlace:
http://www.speccy.org/metalbrain/exo_v4.zip

Bueno, pues ya (parece que) ha llegado a su culminación el gran proceso de optimización de exomizer comenzado por Urusergi, y continuado de forma grandiosa por Antonio Villena, con apenas algunas modestas contribuciones mías. Por una parte, los decompresores se han reducido de forma brutal y son un pelín más rápidos, y por otra se han generado versiones alternativas (no tan pequeñas) optimizadas en velocidad, de forma que podemos escoger entre 4 variantes. La variante 1 resulta especialmente atractiva, ya que al precio de entre 3 y 5 bytes, produce una ganancia del 14% de velocidad.

Aparte de eso, el programa optimizador (exoopt) ha sido reescrito desde cero por Antonio Villena, de forma que se le puede pasar como parámetro la velocidad (y dirección, que antes siempres se utilizaba hacia delante) deseada, y generará automáticamente el descompresor necesario (se le pueden incluso introducir varios archivos como parámetros, y generará la versión más simple si no aparecen cadenas de literales y la completa si aparecen). Este nuevo optimizador aparte de lo que hacía antes (invertir el orden de lectura de los bits, y quitar 2 bits redundantes) efectua otros cambios en los datos, que a veces pueden ser contraproducentes (aumenta un pelín el tamaño), pero permiten simplificar más aún los descompresores.

Las nuevas versiones se pueden encontrar aquí:
http://emuscriptoria.svn.sourceforge.net/viewvc/emuscriptoria/deexo/

y un exoopt ya compilado, aquí:
http://retrolandia.net/foro/showthread.php?tid=48&page=6

La historia de las optimizaciones, por si a alguien le interesa, comenzó por aquí:
http://amstrad.es/forum/viewtopic.php?f=6&t=2608

Nivelaco: debo probar el Exomizer para nuestra próxima producción!

Otra más de optimización ! ?

Oh dios que cracks !. Super util. 1000 gracias.

¡Cuidadín! Se ha detectado un bug en las versiones oficiales (no optimizadas) de los descompresores. Magnus seguramente publicará una versión corregida (la 2.07) pronto, hasta entonces podeis pillar las rutinas actualizadas del repositorio:

http://emuscriptoria.svn.sourceforge.net/viewvc/emuscriptoria/deexo/

Más información aquí:
http://amstrad.es/forum/viewtopic.php?f=6&t=2608&start=150

Hola a todos,

Acabamos de hacer una pequeña nueva release. El código no ha cambiado nada, pero tras ser consultado un par de veces sobre la licencia de las rutinas de descompresión, he decidido licenciarlas bajo la LGPL 2.1 . Los archivos actualizados y la licencia la podeis encontrar aquí:

https://sourceforge.net/p/emuscriptoria/code/HEAD/tree/deexo/