Juegos C64 comprimidos

[BlackHole]

Conozco zx0, pero cuando chequeé no llegaba ni de lejos a los mismos ratios, a no ser que haya evolucionado y lo desconozca.

El objetivo inicial cuando empecé a hacer estas series era comprimir a ratios parecidos a los de Exomizer, pero descomprimir a una mayor velocidad. La diferencia por entonces rondaba el 3%. Con el tiempo evolucionó Exomizer. Con su nuevo algoritmo, mejoró su velocidad de descompresión y aumentó el ratio de compresión. Pero en el último año y medio, el algoritmo propietario de aPLib pasó por una fase de ingeniería inversa en la que aparecieron diversos compresores alternativos, que mejoraron hasta acercarse ahora al 1% de diferencia. En determinados casos incluso gana a Exomizer: ahora hay uno por fuerza bruta que exprime al máximo.

El tema es que la rutina de descompresión que estoy usando tiene casi todos los bucles desenrollados y ocupa 314 bytes, lo cual supera bastante a la de Exomizer en unos 80 bytes, pero eso me permite velocidades más altas. Aunque el objetivo no es tener una descompresión super rápida como zx0, sino que la relación con el tamaño obtenido sea ventajosa.

En este Samurai Warrior, la compresión bruta con Exomizer es de 35661 bytes, mientras que con aPLib es de 36168, un 1,42% superior. El tamaño final del ejecutable con Exomizer es de 36001 bytes, mientras que con aPLib es de 36589 (reensamblado sin pantalla para escribir esto), un 1,63% superior con descompresor incluido. El tiempo de descompresion de Exomizer fue de 7136279 ciclos, mientras que el de aPLib fue de 4218421 ciclos, solo un 59% del tiempo.

Edito: Vale, leo que tú has participado en en el desarrollo del ZX0 y la versión 2.2 es radicalmente diferente a la que probé hace unos años. Una prueba rápida con el ZX0.EXE me da para los mismos datos de arriba, un resultado de 35751 bytes. Tendré que ver cómo adaptar la rutina descompresora para 6502 y ver si realmente es tan rápido como publicita su GIT. Sin embargo en el Arkanoid con aPLib quedaba en 26731 bytes y con ZX0 queda en 28824: ahí no está mereciendo la pena, por ejemplo.

Edito2: He visto que Einar Saukas también tenía un compresor llamado ZX5 que está en fase experimental. Ponía que era lento pero nunca esperé que tanto. He probado con el mismo fichero de arriba y lo ha dejado en 35416 bytes, pero ha tardado ¡38 minutos!
He visto que el enlace al descompresor para 6502 apuntaba a una web sobre Atari 8 bits. Igualmente tendré que ver si la puedo traducir al ensamblador que uso (WLA DX), cuánto ocupa y sobre todo cuánto tarda, pero son cifras interesantes...

[Urusergi]

Mi contribución se ha limitado a un ligero cambio en el formato del compresor forwards del zx0 y sobretodo a la mejora de los distintos descompresores z80, tanto del zx0 como del exomizer en su tiempo.

Yo creo que cuando hiciste aquella prueba fue con el zx7, compresor del mismo autor pero que no tiene nada que ver en cuanto a capacidad de compresión, salvo que estemos hablando de pequeños archivos <1kb que para eso estaba pensado.

Y si solo has tenido que esperar 38 minutos usando el zx5 has tenido suerte. Hay algunos que se han tirado días, para terminar con un fatídico error por falta de memoria RAM Lo bueno de estos formatos (zx0 y zx5) es que aunque tarden en comprimir, la descompresión es endiabladamente rápida en ambos casos.

Cuando te aconsejé que probaras el zx0 imaginaba que ya habría un descompresor para 6502 no me dio por comprobarlo, lo siento.

[BlackHole]

Mmmmmm... he hecho una prueba con ZX5 con el Arkanoid y me ha dado error de memoria. Probaré incrementando la virtual.
Bueno, voy a ver qué consigo con las fuentes que hay por ahí de 6502. Es que el ensamblador WLA DX multiplataforma que uso desde hace muchísimos años cuando hice intros para SNES, no es utilizado por nadie en la escena C64 y debo adaptar el formato de etiquetas y primitivas. Pero ahora que hablas del ZX7 ya me dejas con la duda y ahora mismo ando perdido.

Edito: Obviamente, al hablar del tiempo de compresión es necesario definir qué procesador se usa y qué cantidad de RAM. En mi caso, es un Ryzen 5 4600 con 6 núcleos y 12 hilos, en un sistema con 16GB de RAM DDR4-3200. Reintentando con el Arkanoid que fallaba, pues al cabo de unos 20 minutos ZX5 abortó diciendo que no tenía memoria... pero debe ser un bug del algoritmo: el sistema andaba usando solo un 10% de la memoria física, y aunque añadí 16 GB adicionales de archivo de intercambio para un total virtual de 32 GB, en ningún momento el programa pidió memoria extra.

[BlackHole]

Cuando te aconsejé que probaras el zx0 imaginaba que ya habría un descompresor para 6502

Bueno, ahora que estoy de vacaciones y tengo algo de tiempo, he vuelto a retomar el tema. He ensamblado una rutina en 6502 para ZX0 revisión 1. El código es el liberado por John Brandwood en el GIT de la herramienta Salvador de Emmanuel Marty, aunque hay otros por ahí. En las pruebas preliminares el rendimiento de ZX0 es un 20% más rápido que la rutina de aPLib de Antonio Villena que estaba usando hasta ahora. ¿En Z80 es esa la diferencia de velocidad que obtienes contra aPLib o es superior?

Veo que existe una rutina para ZX0 revisión 2, que necesita binarios diferentes incompatibles. La rutina en 6502 disponible para esta V2 es la programada por Tobias Bindhammer (¿Bitbreaker?) y es más enrevesada para entenderla. No veo que existan versiones en pseudocódigo, tendré que estudiar la fuente en C. Realmente por su carencia de registros y la limitación de sus instrucciones, las rutinas en 6502 son feas comparadas con Z80, sobre todo por su manejo de punteros de 16 bits. ¿Qué mejoras tiene ZX0 V2?

Luego en una web polaca sobre Atari, encontré una rutina en 6502 para descomprimir ZX5, pero lo hacía leyendo de disco. A ver si puedo apañar algo, pero el algoritmo todavía es mucho más complejo y realmente me pierdo.

[Urusergi]

Bueno, ahora que estoy de vacaciones y tengo algo de tiempo, he vuelto a retomar el tema. He ensamblado una rutina en 6502 para ZX0 revisión 1. El código es el liberado por John Brandwood en el GIT de la herramienta Salvador de Emmanuel Marty, aunque hay otros por ahí. En las pruebas preliminares el rendimiento de ZX0 es un 20% más rápido que la rutina de aPLib de Antonio Villena que estaba usando hasta ahora. ¿En Z80 es esa la diferencia de velocidad que obtienes contra aPLib o es superior?

Si, mas o menos. Un compresor increible para lo simple que es.

https://postimg.cc/jDWwL3pg

Veo que existe una rutina para ZX0 revisión 2, que necesita binarios diferentes incompatibles. La rutina en 6502 disponible para esta V2 es la programada por Tobias Bindhammer (¿Bitbreaker?) y es más enrevesada para entenderla. No veo que existan versiones en pseudocódigo, tendré que estudiar la fuente en C. Realmente por su carencia de registros y la limitación de sus instrucciones, las rutinas en 6502 son feas comparadas con Z80, sobre todo por su manejo de punteros de 16 bits. ¿Qué mejoras tiene ZX0 V2?

Nada, no le des vueltas, solo mejora un 1% la velocidad y la rutina es un poco más pequeña, pero para Z80.

Luego en una web polaca sobre Atari, encontré una rutina en 6502 para descomprimir ZX5, pero lo hacía leyendo de disco. A ver si puedo apañar algo, pero el algoritmo todavía es mucho más complejo y realmente me pierdo.

Mejor que te olvides del ZX5, el compresor tiene una limitación de uso de 1Gb de ram (creo que hay que recompilar para subir ese límite) y a veces puede tardar ¡días! en comprimir, sino te salta el error de memoria antes.

[BlackHole]

Sí, conozco el gráfico de la comparativa de compresores porque aparece justamente en diversos GITs de los mismos, pero hay 4 medidas de aPLib y 3 de ZX0, no queda muy claro. Como dijiste que ZX0 era tan brutal, esperaba un porcentaje de velocidad mayor del 20% realmente. En realidad entre aPLib más a la izquierda y ZX0 más a la derecha, se supone que el aumento de velocidad superaba el 100%. No sé si es que las implementaciones en 6502 son malas.

Tendré que probar a ensamblar las diferentes rutinas a ver cómo se comporta, porque la rutina de la V1 que he probado ocupa 196 bytes, y la V2 ocupa 233 bytes y es innecesariamente mucho más compleja. No se parecen en nada a las del Z80 o a las de 68000, el procesador líder en ortogonalidad. En mis pruebas con el Samurai Warrior la V2 gana un 1% de velocidad al descomprimir el juego, pero estaba perdiendo otro 1% al descomprimir la pantalla. Tendré que chequear otras implementaciones hechas por otra gente.

Tengo que averiguar cómo hacer pruebas de profiling con el VICE. Es decir, en un intervalo dado, como el que va desde el inicio de un código hasta un punto de ruptura, averiguar cuántos miles de veces se ejecuta una determinada rutina o pasa por un determinado punto, para optimizar un BEQ o un BNE, para ver cuántas veces se ejecuta una condición o la contraria. ¿Has hecho algo parecido? Por ejemplo, sabes que en Z80 un JR condicional usa 7 ciclos si no se ejecuta la condición y 12 ciclos cuando se ejecuta. En 6502 son 2 y 3 ciclos respectivamente, es importante elegir condiciones positivas o negativas cuando se ejecutan diez o veinte mil veces.

Hoy he probado a comprimir con ZX5 el Arkanoid que falló hace un mes, y ha acabado de comprimir bien, ahorrando unos 660 bytes que no es moco de pavo. El tiempo de compresión es brutal si lo comparamos con otros, pero han sido 36 minutos, nada de horas o días. Puede merecer bastante la pena pararse a ensamblar el código del descompresor.

[Urusergi]

En los demás compresores no sé, pero en el caso concreto del ZX0 está claro que los tres cuadrados corresponden, de izquierda a derecha, a los descompresores Z80 standard, turbo y mega respectivamente.

El problema del ZX0 es qué se ha desarrollado teniendo en mente al Z80, de modo que el formato del compresor y el descompresor son óptimos para ese procesador. El caso contrario pasa con el exomizer, que parece que se desarrolló especialmente pensando en el 6502, y es por eso que metalbrain tuvo que crear en su día un programa optimizador que alteraba el orden de los datos para el Z80 (hoy ya no es necesario, ya que la v3 permite ajustarse a esos mismos parámetros)

[Urusergi]

Sí, conozco el gráfico de la comparativa de compresores porque aparece justamente en diversos GITs de los mismos, pero hay 4 medidas de aPLib y 3 de ZX0, no queda muy claro. Como dijiste que ZX0 era tan brutal, esperaba un porcentaje de velocidad mayor del 20% realmente. En realidad entre aPLib más a la izquierda y ZX0 más a la derecha, se supone que el aumento de velocidad superaba el 100%. No sé si es que las implementaciones en 6502 son malas.

Ah, espera, no te entendí. No te puedo decir que tan rápido va porque yo no soy usuario del aplib, me atengo a las gráficas que ya conoces.
Pero si que he utilizado exomizer v2 y en este caso si te puedo decir que la diferencia es tremenda.

Si te fijas en la tabla, el ZX0 está en una zona solitaria, difícil de alcanzar, lo que indica la eficiencia del método (relación compresión-velocidad de descompresión)

[BlackHole]

Bueno, ayer me puse con el ensamblado de la rutina descompresora del ZX5 presente en la web polaca de Atari. Además, es la que directamente se enlaza en el GIT de Einar Saukas como ejemplo disponible para el procesador 6502... y ¡no me funciónó!

Lo comprobé diez veces por si me había equivocado al copiar el código, probé a comprimir con la opción "classic" por si acaso esa rutina solo soportase un modo clásico (aunque no hay constancia de una V1 vs V2 en la propia página del ZX5, las secuencias generadas son diferentes). Y se quedaba colgado, en un punto determinado empezaba a poner valores erróneos, los cálculos se desvariaban, los offsets de los desplazamientos acababan quién sabe dónde hasta que el emulador saltaba con una excepción al intentar ejecutar instrucciones inválidas en medio de la memoria del C64 que se había corrompido.

Con calma le puse un punto de ruptura un byte antes de que se volviese loco, seguí instrucción por instrucción cuidadosamente todo el algoritmo, y en un momento lee un byte del fichero comprimido para calcular un desplazamiento hacia atrás, y acaba copiando una secuencia desde un lugar incorrecto, como si el algoritmo estuviese mal. Pero el descompresor en Windows dice que ambas secuencias comprimidas V1 y V2 eran correctas.

Estuve demasiadas horas con el tema, acabé con un soberano dolor de cabeza y lo he aparcado. Cuando tenga ánimo, ensamblaré la versión Z80 y lo ejecutaré en un emulador de Spectrum o Amstrad, a ver cómo se comporta y lo seguiré paso a paso igualmente, no vaya a ser que esa implementación en 6502 esté equivocada. El problema con la ausencia de registros de 16 bits en 6502, es que se tienen que suplir con punteros en memoria sobre los que realizar direccionamiento indirecto, con un gasto de CPU brutal y por ejemplo un (no tan) simple EX (SP),HL o un LDI acaban traducidos a una docena de instrucciones cada una.

[BlackHole]

Bueno, he probado a ensamblar la rutina de Z80 y ejecutarla en el ZXSpin 0.7b que es el emulador de Spectrum al que estoy más acostumbrado. He de decir que la rutina "dzx5_standard.asm" del GIT descomprime correctamente binarios comprimidos con ZX5.EXE (v2.0) pero no descomprime bien cuando usamos la opción -c (Classic format v1.*). No encuentro en el GIT código histórico alguno relacionado con un posible ZX5 v1.x con lo que ignoro por qué y para qué está esa opción.

Ahora bien, la rutina Z80 usa muchísimos EX (SP),HL para intercambiar valores de 16 bits. He intentado seguir la lógica del código en Z80 y compararla con la "traducción" a 6502 que estaba en la web polaca, y me he perdido. Parece a grosso modo que es correcta, pero algo debía fallar desde el momento que un desplazamiento se calculaba mal, y como nunca llegaba a la condición de salida, la memoria entera se llenaba hasta que sobrepasaba $FFFF y volvía de nuevo a $0000 corrompiendo todo.

Parece que me tendré que armar de paciencia y ejecutar paso a paso los debuggers de ambos emuladores simultáneamente hasta ver dónde falla. En el VICE sé como activar el debugger cuando la memoria cambia en el último byte que coincide en la secuencia, pero no sé hacer algo parecido en el ZXSpin. ¿Debuggers Z80 que salten cuando cambie cierta posición de memoria?