Juegos C64 comprimidos

[BlackHole]

El 19 de noviembre pasado comentaba que el Samurai Warrior con Exomizer descomprimía en 7136279 ciclos, mientras que el de aPLib fue de 4218421 ciclos. No llegué a comentar que con ZX0 conseguí 3482799 ciclos. Con el segundo trimestre de las clases, no he vuelto a tener tiempo libre hasta ahora con las vacaciones de Semana Santa. He conseguido averiguar dónde estaba el error de la rutina descompresora para ZX5 de los polacos: el registro Y siempre debe estar a cero para que funcione el modo indirecto, y había un momento donde se iba de varas. Con esa rutina de ZX5, el mismo Samurai Warrior tarda 4493723 ciclos, aunque comprime mucho más que Exomizer.

La rutina es lenta, así que voy a intentar "traducir" desde Z80 la versión dzx5_turbo de la web oficial, a ver si por casualidad consigo arañar ciclos, pero me ando volviendo loco con el algoritmo, en serio. Lo bueno es que recompilé el código fuente en Linux, creando un ejecutable de 64 bits optimizado además para mi AMD Ryzen en GCC 12, que tarda un 15% menos que el binario para Pentium y encima nunca se cuelga ni se queda sin memoria. A ver qué consigo estos días, se vienen cosas interesantes.

[Urusergi]

Lo bueno es que recompilé el código fuente en Linux, creando un ejecutable de 64 bits optimizado además para mi AMD Ryzen en GCC 12, que tarda un 15% menos que el binario para Pentium y encima nunca se cuelga ni se queda sin memoria. A ver qué consigo estos días, se vienen cosas interesantes.

Que envidia tengo de la gente que sabe programar y recompilar
Estaría bien si lo subes al repositorio de Einar https://github.com/einar-saukas/ZX5 que hay mucha gente que se queja del problema del límite de memoria.

Si quieres puedo echarte una mano con el descompresor del ZX5

[BlackHole]

Bueno, es el compilador de C el que hace toda la magia. Lo hice en Linux porque el paquete del GCC es nativo para esa plataforma. El ejecutable se compila en 3 décimas de segundo (no es coña), no hay ningún mérito, cualquiera puede hacerlo. La cosa es que los flags que usé analizan la plataforma en la que se trabaja, el ejecutable creado está específicamente generado para los juegos de instrucciones de un AMD Ryzen y puede que ni siquiera vaya en procesadores Intel, no es universal, y por supuesto es un binario ELF que llama a librerías Unix, no un binario PE que llame a DLLs de Windows.

Antes de aventurarme a subir nada, tal vez debería probar a instalar un compilador moderno en Windows, un MinGW actualizado que incluya GCC 12, porque el que tenía era todavía para Windows 7 y está super obsoleto. Las fuentes oficiales del ZX5 están diseñadas para el Open Watcom C+ Compiler, un fork del Watcom Original de los años 90 cuya versión estable ya tiene 12 años y parece fuera de mantenimiento. Los flags (opciones del compilador) no funcionaban en el GCC de GNU, tuve que ignorar la mayoría y el código soltaba warnings. Para Microsoft Visual Studio no creo que tampoco sirvan, aunque yo no soy desarrollador y no tengo experiencia con él. Ni siquiera tengo (ni quiero) cuenta Microsoft para descargarlo.

Ya te mandaré MP si me quedo atascado con la rutina. El problema es que el código está saltando continuamente con EXX para barajear los 3 desplazamientos con los registros BC' DE' y HL' y de repente vuelve al juego principal de registros en medio de una rutina. Acabo teniendo que debuguear paso a paso y la traducción a 6502 es larga y tediosa por la falta de registros. ¿Tú sabes 6502?

[Urusergi]

Ya te mandaré MP si me quedo atascado con la rutina. El problema es que el código está saltando continuamente con EXX para barajear los 3 desplazamientos con los registros BC' DE' y HL' y de repente vuelve al juego principal de registros en medio de una rutina. Acabo teniendo que debuguear paso a paso y la traducción a 6502 es larga y tediosa por la falta de registros. ¿Tú sabes 6502

Lo gracioso es que mi primer ordenador fue un CPC464, pero mucho antes de aprender ensamblador z80 (2012) tuve que estudiar un poco de 6502 y 80x86 (1993) y 68000 (1998) por motivos académicos. Pasado tanto tiempo, puedes hacerte una idea de lo poco o nada que ha quedado en mi memoria de todo eso

[BlackHole]

Buenas y tórridas noches. Las sucesivas olas de calor que venimos sufriendo este verano de 2023, han trastocado mis ritmos circadianos, salgo a pasear al amanecer, duermo de día y los únicos momentos donde la cabeza está despejada para poder pensar en programar, son estas pocas horas de la madrugada. Hoy vengo a presentaros mi versión de The Way of the Exploding Fist, un juego desarrollado en 1985 por la compañia australiana Beam Software y publicado por su sección britanica Melbourne House.

Aunque el juego acabó apareciendo más tarde para casi todas las plataformas, la idea original se desarrolló para Commodore 64. El hecho de tener separadas las empresas de desarrollo y distribución era extraño por la época. Melbourne House acabó siendo vendida en 1987 a Mastertronic y Beam Software siguió programando para la Nintendo NES. En 1997 recrearían Melbourne House, pero en 1999 se volvió a vender a Infogrames. Beam Software siguió haciendo juegos para consolas y PC hasta llegar a Playstation 2 y XBox 360. En 2005 Atari volvió a venderles el nombre Melbourne House, se renombró a Krome Studios Melbourne, pero terminaron desapareciendo en 2010. Larga y ajetreada existencia.

Empecé a trabajar en este crack en Octubre del año pasado pensando que iba a ser cosa fácil de un fin de semana, pero como se complicó la cosa, lo dejé apartado. Lo intenté retomar del cajón de pendientes en Abril (tengo muuuuchas cosas pendientes a medias), pero de nuevo los estudios del ciclo de ASIR me obligaron a volverlo a dejar en barbecho hasta ahora. ¿Por qué la complejidad del crack, os preguntaréis? Pues porque quería dejar la pantalla de carga, con el sonido digitalizado de la intro y con el juego, todo en un mismo fichero... y las cuentas no daban por mucho que apretase. Los datos originales ocupan 74912 bytes y está claro que no se puede meter todo a la vez en memoria. Aunque si Remember lo hizo en 1997, por cojones tenía que poderse, no iba a ser yo menos que Jack Alien, jajaja.

La solución fue reprogramar la rutina que reproducía el sonido digitalizado y relocalizar la forma de onda a otra posición completamente diferente después del espacio que quedaba tras el todo el material comprimido. Como la rutina de descompresión quedaba ahora en medio del sonido y la pantalla, tuve que partir el juego en 2 trozos para descomprimirlos por separado. Cierto que al hacerlo así perdí capacidad de compresión, pero los compresores actuales son infinitamente mejores que los existentes en los 80 y 90. Al final mi versión ocupa 174 bloques (134 del juego y 40 de la intro) y tarda unos 5 segundos (0.6+1.1+3.3) en descomprimir, pero cuando te pones a comparar con los 25 segundos que tarda la versión de Remember de 200 bloques, realmente no hay color. Lamentablemente no había sitio para comprimir una pantalla optimizada, pues carecía de los 8000 bytes adicionales necesarios para reordenar el bitmap. No he visto los 100 cracks del juego, pero creo que es la versión más pequeña existente.

Exploding Fist [BH][2023].d64.gz

C64 The Way of the Exploding Fist - 1985 Melbourne House

(43.27 KiB) Descargado 203 veces

[BlackHole]

Buenas noches. Revisando mis posts, me he dado cuenta que no había subido a Zona de Pruebas un fichero que lancé el pasado 1 de junio de 2023. A raíz de un vídeo de YouTube donde se descubría que la versión británica distribuida por Alligata del famoso juego de Ópera Soft Livingstone Supongo llevaba de serie un bug en el máster de la cinta, que impedía acabar el juego tras bloquearse en cierta posición, decidí realizar una versión comprimida de la versión española, que curiosamente estaba muy pobremente crackeada (por decir algo), pues solamente se distribuyó un cartuchazo de un volcado de la memoria.

La versión española incorpora una pantalla de carga que no se parece a la de Spectrum o Amstrad CPC, sino que curiosamente es similar a la versión del PCW. Aparte de volver a utilizar el SPOT para optimizar la pantalla, arañando un buen puñado de bytes en el resultado final, esta vez no he utilizado aPLib como en previos compactados más arriba, sino que he usado el compresor ZX5 del brasileño Einar Saukas. Si bien con su otro compresor ZX0 conseguimos velocidades de descompresión vertiginosas, con el ZX5 se consiguen ratios de compresión mejores que los compresores LZSS existentes, pero a cambio de un tiempo de compresión brutal. Si con aPLib tardamos pocas décimas de segundo, con el ZX5 en el Livingstone ha tardado 17 minutos en comprimir, y en otros juegos se sube a la media hora en un PC de 3600 MHz.

Si una prueba con Exomizer dejó el juego en 103 bloques, con ZX5 se conseguían 100 bloques, que sumados a la pantalla optimizada y comprimida, dejan esta versión que hoy subo aquí en 117 bloques. La página GIT del proyecto ZX5 no incorpora las fuentes para descomprimir en máquinas 6502; así que buscando soluciones, tuve que tirar del hilo de la escena polaca de Atari donde había una rutina, aunque es algo lenta. Como quería distribuir esto aprovechando el tirón que el bug recién descubierto había dado al juego, pues lo he dejado como está.

Una de las curiosidades que tenía el original, era que añadiendo la cadena ":OPERA" en la orden LOAD de la cinta, se activaba un truco de vidas infinitas. He conseguido replicar el efecto, haciendo que funcione cuando se llama desde disco/IEC. Únicamente tenemos que insertar la cadena "OPERA" en cualquier lugar de la línea de comandos tras cargar el juego o iniciarlo, para que sea detectado y se active el truco, para intentar pasarse este imposible juego. ¿Podrías pasartelo con las 7 vidas originales?

Livingstone Supongo [BH][2023].d64.gz

C64 Livingstone Supongo - Opera Soft 1987

(29.69 KiB) Descargado 228 veces

[alt]

¡Muchas gracias, Fran!
¿Te/os suena que haya más títulos de C64 que utilicen esa forma de cargar el programa para modificar el juego?

[garillete]

Idem... Cuando pueda los pruebo... El Livingstone al igual que el Abu Simbel lo veo siempre dificil pero lo veo como una suerte de reto y me niego a ponerles trucos... Y como soy mal jugador por regla general pues me matan a la primera de cambio me desanimo lo dejo y al tiempo vuelta a empezar... Si le pongo vidas le quito el aliciente... Hay juegos que te los pasas y no volverías a ponértelos nunca mas..

[BlackHole]

¿Te/os suena que haya más títulos de C64 que utilicen esa forma de cargar el programa para modificar el juego?

No sé si fue una ocurrencia puntual del programador del Livingstone o algo que Ópera Soft pudo haber replicado en más juegos. Quizás estaría bien hacer una lista de juegos de Ópera para C64 y comprobarlo. Lo que estoy seguro es que el truco lo leí en una Micromanía de la época, que si no, hubiese sido casi imposible averiguarlo incluso tomándose la molestia de desensamblar el código, pues a nadie se le ocurre rebuscar valores almacenados en el buffer de teclado del BASIC, en serio.

[BlackHole]

Buenas tardes. Casi 17 meses después de mi última entrega en este hilo, este día de Reyes del recién estrenado 2025 tengo el gusto de presentaros mi versión de Green Beret, una conversión de la máquina arcade de Konami de 1985, desarrollada en 1986 por la compañía británica Imagine, una de mis favoritas como habéis visto a lo largo de esta serie.

Como quien no quiere la cosa, empecé a trabajar en este proyecto allá por Septiembre de 2016, incluso antes del primer juego posteado aquí. Pero diversas complicaciones fueron aparcándolo, retomado en diversas ocasiones en todo este tiempo, y finalizado ahora en Navidades. Mi intención inicial era rehacer la pantalla de créditos inicial para mostrar los nombres completos de los autores, y buscar una pantalla de carga alternativa a la original. Para crear la pantalla utilicé diversos trabajos ajenos, un dibujo anónimo de Julio de 2009, y un logotipo retocado de una demo de 1986.

La complejidad del proyecto vino sobre todo porque el juego ocupa más de 63 KB de memoria RAM. Solo quedaban libres 448 bytes no contiguos, para poder hacer los malabarismos. Empecé con la versión de cinta, hasta que me di cuenta que la versión de disco original era ligeramente diferente y acababa comprimiendo mejor. Debido a la poca memoria libre, he tenido que partir la rutina descompresora en 2 partes, con cuidado de no corromper el área de la pila del procesador, que está fija entre $0100 y $01FF.

Para poder cambiar los créditos iniciales y el espaciado del logotipo del nombre, tuve que encontrar la rutina que imprimía cadenas de texto y analizar la estructura interna de caracteres de control. No tenía ni un solo byte de maniobra, había que reemplazar texto en el mismo hueco. Menos mal que los símbolos de coordenadas X/Y de los textos, fueron fácilmente identificables y pude reorganizarlos. El original siempre me dejó mal sabor de boca, como si lo hubiesen hecho mal deprisa y corriendo.

El juego original pasa de tener 64732 bytes a quedar comprimido en 29154 bytes con ZX5. No me acuerdo si lo comenté en el pasado, pero el ZX5 distribuido para Windows está para 32 bits y en ocasiones se queda colgado por superar los 2 GB de memoria temporal de trabajo. Tuve que recompilarlo con GCC 14 de Linux para 64 bits, gracias a que el código fuente es público, y aún así los juegos de 64 KB tardan casi media hora en comprimirse.

Tras comprimir el juego, queda memoria libre para mostrar la nueva imagen y la música original de la carga desde cinta, quedando todo empaquetadito en solo 35317 bytes que generan un archivo de 140 bloques de disco (117 para el juego y 23 para el resto). Como siempre en un Commodore 128, o su emulador VICE x128, se activan los 2 MHz que duplican la velocidad de descompresión. Otras herramientas usadas en el proyecto han sido el optimizador de imágenes SPOT y el relocalizador de músicas SIDreloc.