Nuevos cracks de juegos clasicos.

[josepzin]

"Vera Cruz", la verdad no me suena...

[marcos64]

Vives cerca? 

[josepzin]

Estuve viendo en un mapa para estar seguro pero creo que estamos mas o menos a la misma distancia o quizás tú mas cerca

[marcos64]

Me referia a Santa Fe de la Vera Cruz. No se porque me sonaba que eras de esa zona. La edad haciendo de las suyas 

[josepzin]

Yo estoy bastante mas abajo
Al centro de Argentinia.

El que está muy cerca de ahí es @cubelindo

[marcos64]

Extend ha creado un nuevo crack con muchos bugfixes de un super clasico: Aztec Challenge

Juego que, estando lleno de bugs, aun asi tenia un atractivo especial. Me parece que la musica tenia gran parte de la culpa 

Quizas el juego era un poco demasiado ambicioso para la epoca.

EDITO: Un fix del fix https://csdb.dk/release/?id=257823




EDITO2:

Production Info
Submitted by Grue on 11 December 2025
Aztec Challenge

As usual, I used the binary from the original game to make the source code for the game and then proceeded to make fixes.

The original game was clearly coded with a machine code monitor, as the memory management used a lot of NOPs and gaps between the routines. There are strange bugs which suggest that something was patched away by altering the memory with a monitor.

I just wanted to fix the stairs level, but then the usual happened..

There is a heroine in the cover art of the game, and now you can choose to play as her by pressing F7 in the menu. The colour of the hair of the Aztec people is not white/yellow, but I decided to not care.

These notes were made during the development of this fix, some things have been forgotten for sure. My main idea was to not change the game too much, but instead to make some fixes to make the game look less jarring to the eye.

One problem with the original game is that it uses dummy loops for delays, also some levels change the timing as the levels advance. The music is played using the default CIA interrupts instead of the raster irq. When timing the screen by waiting for the proper rasterline, you'll miss the line if the music is playing at the same time. Because of this, I chose to time screens with lda $d011, bpl -. This works quite nicely on PAL systems, but because there is much less time on NTSC systems when the 9th raster line bit is on, you might see occasional problems. This could be solved by using raster irq's instead, but that would have changed the game timings too much in some of the levels.
Choices choices, if someone else wants to take this to the next level, I can share the sources, just ask.

Here is a list of the changes and some other things:

The original game told you to hit fire to start the game between the levels. It didnt react to the fire button instantly or sometimes at all, as the fire button was read between the two dummy loops that flashed the "1 up" text during the requester.
- Changed the dummy waiting loop to check for the firebutton inside the loop.

The Gauntlet
- The initial arrow was shot instantly. It felt unfair and in the end it turned out to be a bug.
- fixed the initial counter to be read from the level's initialization data instead of setting it to #1 which caused the instant shot.
- the original code did eventually set that value correctly after the player had already died.
- When a death occurred, arrows were flashed in the wrong positions before the level was reset.
- disabled arrow sprites on death

The Stairs
- Fixed the scrolling of the stairs
- the original code had 4 bugs
- wrong colors, hires instead of the intended MC mode
- What are the correct colours? The hero has white hair on the gauntlet and stairs levels. Is it because both of the levels are supposed to be yellow?
- Changed the colors to match the pyramid as seen in the gauntlet level.
- People will hate me for this for sure...
- The addional color init routine didnt loop, it just made the wrong color blocks
- D011 scrolling didnt wait for a new frame
- Copying new stairs to the top of the screen while scrolling was done incorrectly.
- The initial 3 stones were always in the same positions.
- Randomized the initial state
- Fixed the controls, the original code was very optimistic and caused anomalies when fire/up/down was used.
- Now just Left/Right works on the stick as intended.
- ntsc testing brought the jerky scrolling back, there doesnt seem to be enough raster time available in ntsc with this method.
- I ended up predrawing the screens and switching the screen pointer instead of printing characters into the screen mem in real time. Scrolling is now nicer on ntsc as well.

The Temple

- Cleared sprite to sprite collisions on init to prevent deaths with no apparent cause.
- Sometimes the hero teleported back the left when it should have not, there was a jump to wrong place in the move code.
- fixed

The Vermin
- Fixed the scrolling
- The vermin screen first scrolls the background characters and then copies the background chars to the same place again
- why? its not necessary and the code seems like it's structured to be copying a more complex scrolling background. Looks like WIP to me
- I'm not talented in pixeling and since the original didnt scroll anything there, I just commented the character scrolling code out.
- The original vermin screen timed the action by using a dummy loop (yes you read it right, what an absolute mess). It's pretty much impossible to fix it to be 100% like the original, so close enough needs to suffice here.
- The Vermin screen updated some of the vermin x-coordinates several times per frame seemingly at random, if it was near the hero.
- this turned out to just be a coincidence, the bug was in the randomization code of the next set of vermin.
- The code for the falling spiders didn't check if the spider had scrolled out of the screen during falling, it just teleported to the right at coordinate 255 instead.
- fixed the original code to check if the x-coordinate had reached zero during falling as well.
- MSB bit handling triggered when the x-coordinate reached zero, causing the sprite to flash for one frame as it teleported behind the left border.
- fixed the check, checking $ff instead of 0

HopAztec
- The right hand death arrow was left hanging in the air after hitting the hero
- Hide it after a hit
- The arrow is a MC sprite, but the MC bit wasnt set for the arrow.
- Fixed
- The color of the hero's clothing changed from white to yellow on death
- Fixed

Piranha
- The hero is split in two
- The collision detection is broken this way, and cannot be fixed without recoding the whole logic.
- Changed the splashes of the piranhas to red when they snap the hero.
- it's done in a random order and only if a "coin flip" hits.

The Bridge
- A piece of the bridge disappeared at the msb bit change.
- The reason was the check for zero, if the x-coordinate reached 0 and the msb was in, it turned off and the sprite instantly teleported behind the left border causing a momentary bridge piece to flash on the screen. Changed the code to change the msb when the coordinate reaches $ff instead.
- The color of the hero's clothing changed from white to yellow on death
- Fixed

General changes / fixes

- The game uses decimal mode for counting the score, but the irq routine didnt have cld at the start of it, which can cause anomalies, mostly in the music and sfx department.
- Added cld at the start of the irq-routine.
- A lot of initialization bugs here and there, which were way too numerous to even remember.
- A lot of unneeded data was removed and tidied up. I think this must be the smallest version of Aztec challenge there is.
- not necessary anymore as the heroine gfx got added.
- Tidied up the transitions, now it turns the screen off when the screen mode is changed etc.
- F5 key for B&W mode
- This was a childhood trauma. I had an old b/w tv connected to my C64 with an rf-cable, and you couldn't see the piranhas. So you just died without any apparent reason on that level. When I saw that at my friends place on a color tv, I understood why I was dying all the time...
- The character case change is now locked
- NMI (hitting restore) restarts the game
- Turned sprites off at the init.
- Added rand8 from Codebase64 for a better random source than dc04 reads, and applied it to the places where it matters.
- Introducing the better random algorithm made the game a lot less predictable and perhaps more difficult.
- Added alternative Heroine sprites, you can activate these by pressing f7 in the menu.
- This is a one way change as in real life, there's no going back.

About the music

It is what it is, the music changes in the game as the player advances beyond certain pointsin the level.
- when the music data changes, a pointer address is changed but the index is not (this is an intentional ugly hack in the original code)
- when the player advances more, the waveform is changed in the sid but this is not in relation to the note data, it depends on how fare in the level you are.

When you consider this, the music may sound buggy. But it is what it is. I think there should be a completely different music routine to have it work properly, and it's out of scope for this project.

Phew, there were quite a lot of bugs there, and I'm sure theres still a ton left. Even though it is a beloved classic game, that doesnt mean it was bug free.

Bugfix fix notes:

- When restarted the game, the Cosmi logo was corrupted.
- fixed
- It was possible to choose heroine again after restart.
- fixed
- Music broke completely after death at piranha level
- fixed
- There was still arrow left hanging in the air in hopaztec if msb bit was on on arrow sprite
- fixed

- On the stairs, starting of the screen was ugly and it was super ugly when restarting the level after death.
- Several possible reasons for that, but I tried to fix it by blanking the screen momentarily after death.
- this calmed down the screen and even it wasnt the main cause of the ugly execution I decided to leave it.
- Start of the stairs was randomly ugly, the reason was that screen was painted without waiting the raster line being out of visible area.

- ended up fixing all the levels by blanking screen at the start and and then paint the screen before enabling it again.
- I was going to do that already earlier but totally forgot about it...
- some levels may still show some inpurities at the start, like in the gauntlet no sand at the lowert part of the screen for the first moment of the level
- also piranha level drawing is boiled into actual playcode so it is what it is.

- On the bridge level hero sprite flashes occasionally when moving upwards, its hard to avoid as the screen update is not synced to $d012, and if we start to wait for $d012 lines for the sprite writes, timings mess up on later levels when it gets a lot faster.



Tools used:
6502 Bench
64tass
retrodebugger
VSCode editor
Exomizer

[josepzin]

No lo tuve en la época y ya luego cuando me llegó no me terminó de enganchar especialmente.

[marcos64]

Nostalgia ha sacado una version mejorada del crack del Street Rod

Onesided, fixed glitch in graphics when changing screen modes, color fixes and text fixes

https://csdb.dk/release/?id=257635



Y ya tenemos arbolito 

[josepzin]

Y ya tenemos arbolito 

Un clásico

[josepzin]

Seguro esto ya se publicó por este hilo, pero a raiz del programa del Dany que se termina el Impossible Mission, estuve leyendo las mejoras de esta versión "Revisited" y la verdad es para sacarse el sombrero!!

Impossible Mission Revised
https://csdb.dk/release/?id=242553&show=notes#notes


Aquí va una traducción de todo lo que hicieron, espectacular. Ya solo que marque en el mapa las habitaciones que falta terminar de revisar es una gran ayuda, pero tiene muchas cosas mas.

# Impossible Mission Revised
**Basado en la versión original de Australia (AUS).**

El juego no tenía protección de disco, pero quedaban al menos 3 "bombas" en el código. El programa verifica si la dirección `$d024` contiene `$0a`; si no, se bloquea. El juego realiza un `JSR` (saltar a subrutina) al registro CIA `$dd03` donde almacena un `$60` previamente en el código, el cual luego se sobrescribe. Finalmente, tiene una llamada IRQ a la *zero page* solo para actualizar el contador de frames, que se sobrescribe al reiniciar. Todo esto ha sido eliminado y el código se ha limpiado.

Es un movimiento audaz intentar mejorar un videojuego perfecto; uno podría pensar qué demonios se podría mejorar. Revisé todos los *ports* del juego en YouTube y noté que, en la versión de BBC Micro, la pantalla temblaba cuando el héroe caía desde una altura considerable. En la versión de PlayStation, había una función excelente donde el mapa marcaba qué habitaciones habían sido vaciadas tras registrarlas. También encontré algunos errores (*bugs*) y lugares para pulir y hacer el juego aún más disfrutable de lo que era originalmente.

Para ofrecer un mayor desafío, se han rediseñado las plantillas para cortar las piezas de los puzles, de modo que las formas familiares ya no son exactamente iguales. Además, el generador de números aleatorios (RNG) ahora se gestiona de forma que cada partida sea diferente.

Personalmente, estoy muy contento con el resultado; ¡me encanta este juego, y ahora incluso más!

Los "dolores de cabeza" habituales pueden leerse en el registro de cambios a continuación.

---

### CAMBIOS:

* **Generador de Números Aleatorios (RNG):** Se insertó el algoritmo X ABC de *codebase64* en el código base.
    * Al inicio del juego, debes interactuar con el joystick 2 para añadir entropía al inicio del RNG.
    * El jugador debe presionar el botón del joy2 y, al soltarlo, la semilla del RNG se establece con la información de la interacción del usuario.
* **Rutina de espera:** Se cambió el bucle de espera vacío por una espera basada en `$D012`, en lugar de quemar ciclos de CPU para medir el tiempo.
    * Esto corrige los tiempos en sistemas con aceleradores de CPU.
* **Reloj del juego:** Ahora se ajusta con información PAL/NTSC. 1 segundo equivale a 60 frames en NTSC y 50 en PAL.
    * El juego original corría más lento en sistemas PAL, ya que un segundo se contaba como 60 frames en todas las versiones.
    * Usé la detección PAL/NTSC del juego para configurar el valor del tic del reloj.
* **Efectos de Game Over:** Tras la risa de "Game Over", la pantalla tiembla y se pone en blanco; la pantalla no quedaba centrada y el color negro asomaba por los bordes.
    * Se restauraron los valores por defecto de la pantalla tras el temblor.
* **Audio:** Se añadió código para reproducir los *samples* con más volumen en el chip 8580.
    * En el emulador Vice parece distorsionar, pero suena bien en hardware real.
* **Compresión de datos:** TNT ayudó proponiendo el empaquetado de los gráficos de Elvin Atombender.
    * TNT suministró los datos empaquetados y la rutina de descompresión.
    * La información de 1k de color ahora solo ocupa 157 bytes.
* **Guardado de archivos:** Se simplificó el proceso de guardado.
    * El original era demasiado complicado: primero guardaba "HI2", luego borraba "HI" y renombraba "HI2" a "HI".
    * El nuevo sistema utiliza sobreescritura directa.
* **Memoria:** Las rutinas de IRQ y guardado de archivos se movieron a una zona más baja de la memoria.
    * El guardado funciona ahora con el *Action Replay* activo.
    * El FC3 corrompe la pantalla tras guardar, pero el guardado funciona y puedes reiniciar el juego usando RUN/STOP, RESTORE o ambos.
* **Escena de Game Over por tiempo (Time-out):**
    * Se corrigieron errores donde el último byte del banco era visible y los sprites del ascensor hacían que la escena pareciera rota.
    * Ahora el último byte del banco se limpia durante el temblor de pantalla y se restaura después.
    * El sprite de la pared del ascensor se apaga y el sprite del techo se mueve con la pantalla. La escena se ve mucho mejor.
* **Habitaciones 15 y 20:** Tenían asignado incorrectamente color de alta resolución (*hires*) a teselas multicolor (MC).
    * Se cambió el código de color para mostrar las teselas como MC. Esto corrige lo que considero era un error original.
* **Mapa mejorado:** Si una habitación ha sido vaciada al registrarla, aparece hueca en el mapa del jugador.
    * Esto hace el juego un poco más cómodo de jugar (fue sorprendentemente difícil de añadir).
* **Caídas:** Si el jugador acelera al caer por encima de cierto umbral, la pantalla tiembla.
    * Se implementó un temblor aleatorio de 5 frames en `$d011`.
    * Se añadió un efecto de sonido para el golpe contra el suelo (*thud*).
    * Se corrigió un error del original donde el byte de caída no se activaba al morir, causando procesamiento innecesario del héroe.
* **Formato de hora:** El reloj del juego está ahora en formato de 24 horas. (Dudo que los agentes oficiales usen AM/PM para evitar confusiones).
* **Puzles de notas:** Las habitaciones de puzles de notas ahora están marcadas en el mapa con un patrón de tablero (ajedrezado).
* **Guarida de Elvin:** La puerta de la guarida de Elvin se marca en el mapa, pero primero debes recolectar los objetos necesarios.
* **Reloj de Sprites:** Código finalizado; muestra horas y minutos. (Muestra el reloj en el campo de juego, lo cual fue un dolor de cabeza).
* **Optimización de memoria:** Me quedé sin espacio de nuevo. Se empaquetó más contenido de la pantalla final de Elvin y se movieron bloques grandes de código bajo la E/S (principalmente los encargados de la aleatorización inicial).
* **Contraseñas:** El juego ahora tiene 32 contraseñas diferentes. Se elige una al azar al empezar. (Luego se redujo a 24 para que quepan en una sola página de memoria).
* **Renderizado del reloj:** En habitaciones normales, el reloj se renderiza con caracteres en la esquina superior derecha.
    * No se muestra mientras el jugador registra objetos o en habitaciones de puzles de notas por conflictos con el set de caracteres.
* **Animación de robots:** Nuevos frames de animación por Trurl.
    * Ahora puedes ver la parte trasera del robot si el juego lo elige al azar.
    * Fue muy difícil de añadir porque el juego tenía su lógica muy ajustada a solo 6 frames. ¡Ahora tenemos 12 frames y aún queda algo de memoria!
* **Interfaz:** Corregido un error de color en la interfaz del teléfono en el mensaje "orientation corrected".
* **Diseño del reloj (Sugerencia de "the wolf" de Lemon64):**
    * El reloj corre de 12:00 a 18:00 para que el punto y coma encaje limpiamente.
    * Debido a limitaciones de espacio (16 píxeles), se usaron desplazamientos de bits (LSR/ASL) para crear un espacio de 3 píxeles para el punto y coma entre los dígitos.
* **Tipografía:** Preparativos para cambiar la fuente ROM de Commodore por la fuente "7-up".
* **Punteros de Sprites:** Los sprites extra de los robots se movieron a números de puntero pares para evitar conflictos con la lógica de "mirar atrás" del juego.
* **Desafío:** Plantillas de puzles modificadas para aumentar la dificultad.
* **Puntuación:** Corrección en el cálculo de puntos para contar segundos en el intervalo de 0-6 horas en lugar de 12-18.

---

### Herramientas tradicionales utilizadas:
64tass, Ghidra, 6502 Bench, 010 Editor, Spritepad Pro, Charpad Pro, VSCode editor, Retrodebugger, Vice, Exomizer, CC1541, Dart, DirMaster.

[marcos64]

Aunque no es un juego que a mi me guste, es todo un clasico: Head Over Heels Extended

https://csdb.dk/release/?id=262697

# Diario de Head Over Heels para C64: encajando un clásico de Spectrum

## Cómo empezó todo

Conocí este juego gracias a Barfly y decidí investigar si podía hacerlo un poco más rápido.

La historia de siempre: descifré la cinta original, exporté el binario, lo importé en 6502bench y comencé el arduo trabajo de convertirlo en código fuente compilable.

Después de aproximadamente una semana, había logrado ordenar gran parte del caos del direccionamiento indirecto y localizar la mayoría de las tablas que contenían direcciones que debían convertirse en etiquetas. Esto permitió que el código fuente pudiera compilarse sin demasiados problemas de asignación de memoria.

## Metiendo la IA en el lío

El código del juego resultó ser muy complejo y difícil de seguir, así que en ese momento decidí incorporar IA al proyecto. Tenía una suscripción de pago a Claude Code, de unos 20 euros al mes, porque quería aprender cómo funcionan estas herramientas. Tengo 52 años, una edad demasiado joven como para ignorar la IA si quiero seguir trabajando hasta la jubilación.

Una vez que pude identificar las rutinas responsables de dibujar los gráficos, vi posibilidades de mejora. Pero no había mucha RAM libre disponible, así que decidí eliminar la música y los efectos de sonido para liberar unos 120 bytes de página cero y casi 8 KB de RAM. ¡Un sacrificio bastante drástico! Por supuesto, el juego necesita sonido, pero decidí no preocuparme por eso en esta etapa.

Le pedí a Claude que buscara optimizaciones. Al principio no encontró gran cosa, pero cuando empecé a guiarlo rutina por rutina y a indicarle qué debía buscar, produjo muchos resultados útiles.

Aquí va una pequeña advertencia: la IA no es inteligente en el sentido humano. Es una herramienta, y lo que obtengas de ella dependerá de cómo la utilices. Después de cada cambio sigue siendo necesario verificar y probar todo. A veces los resultados son subóptimos, así que debes entender qué intentas lograr y orientar a la IA hacia otro enfoque.

En resumen, la IA es una herramienta excelente, pero como cualquier herramienta, necesitas entender lo que haces para utilizarla eficientemente. Ahorra muchísimo tiempo y, en general, parece introducir menos errores que yo... aunque no siempre. Tuve que restaurar copias de seguridad más de una vez porque estropeó las cosas hasta el punto de que ni ella misma podía arreglarlas. En parte fue culpa mía por no probar con suficiente frecuencia.

## Las primeras mejoras reales y el primer pánico por memoria

Resumiendo: conseguí ahorros significativos de ciclos de CPU, dependiendo de la tarea. En algunos de los peores casos, las mejoras suponían miles de ciclos.

La desventaja era que me quedaban apenas unos 3,5 KB de memoria libre, así que volvió el clásico pánico por la memoria del C64.

No había forma de incluir la música original, así que estudié la posibilidad de conservar los efectos de sonido. Eso me llevó a la rutina musical. Y vaya desastre.

Me llevó varios días hacerla reubicable. Había saltos definidos dentro de los propios datos de los efectos, código automodificable y punteros a rutinas de efectos.

Al final conseguí convertirla en código fuente reubicable. Claude ayudó parcialmente, pero no pudo descifrar las partes más complicadas, así que esas tuve que resolverlas manualmente.

Volviendo al tema: finalmente logré recuperar los efectos de sonido, pero apenas quedaban unos 200 bytes libres de RAM, y aún quedaba mucho por hacer.

## Exprimir todos los trucos de velocidad posibles

Para los usuarios de C128 activé el modo de 2 MHz en los bordes y durante el renderizado de habitaciones cuando la pantalla está apagada. Esto hace que el juego funcione de forma mucho más fluida.

Los usuarios de Ultimate64 pueden usar el modo turbo con Turbobit activado. El juego funciona sincronizando cuadros cada cuatro fotogramas. También podría funcionar con una SuperCPU real, aunque no lo he probado. Sí funciona con VICE xscpu.

Esto también me permitió limpiar las transiciones. Ahora hay menos parpadeos de pantalla que en el juego original. Además, el juego original mostraba un molesto punto blanco en el borde causado por escrituras constantes de color. Eliminé ese código porque solo se utilizaba en los menús y no afectaba a la jugabilidad.

## Una pequeña mejora de calidad de vida

Añadí soporte para el segundo botón de disparo del joystick.

* Head utiliza el segundo botón para tocar la bocina, si has recogido tanto los donuts como la bocina.
* Heels lo utiliza para recoger y soltar objetos una vez que has conseguido el bolso.
* Cuando Head y Heels están combinados, el segundo botón controla la función de recoger y soltar objetos.

Es difícil hacer mucho más, porque queda muy poca RAM disponible: prácticamente todo está en uso.

## Persiguiendo la versión de Spectrum

En algún momento empecé a preguntarme cómo este juego había logrado caber en 48 KB en Spectrum.

Entonces recordé lo obvio: el ZX Spectrum tiene una resolución de 256×192, frente a los 320×200 del C64.

También me di cuenta de que, con esa resolución, pasar a la siguiente línea del bitmap requiere simplemente incrementar el byte alto de la dirección, mientras que en el C64 hay que sumar un valor de 16 bits para obtener la dirección de la línea siguiente. Esto puede resolverse mediante tablas, pero esas tablas consumen espacio valioso. Cambiar de bitmap a fuentes también permite ahorrar memoria para más optimizaciones.

Actualmente el juego utiliza 32 caracteres por línea y 25 líneas en pantalla repartidas entre cuatro fuentes diferentes. La pantalla original de Spectrum solo tenía 24 líneas de altura.

Por desgracia, tuve que implementar una rutina raster estable para gestionar los cambios de fuente. Como podrás imaginar, ejecutar un juego tan complejo provoca mucho jitter, con todas las consecuencias habituales para las interrupciones IRQ.

Al final no estoy seguro de haber ahorrado tiempo de CPU en este aspecto, porque ahora se consume mucho tiempo en interrupciones. Sin embargo, sí obtuve una gran cantidad de memoria adicional, lo que me permitió añadir código de aceleración en otras partes. Eso sí marcó una diferencia importante.

También tuve que eliminar el bitmap de carga original del juego principal, porque mantenerlo habría complicado demasiado la gestión de memoria. En su lugar, añadí una introducción independiente con la imagen de carga y la música del título que había retirado del juego principal.

## La madriguera del guardado en checkpoints

Luego empecé a investigar cómo guardar puntos de control en un archivo.

Al principio parecía sencillo, porque el juego ya mantenía ranuras de checkpoints y permitía continuar después de perder todas las vidas. Si salías y comenzabas una partida nueva, te preguntaba si querías continuar una partida anterior.

Pero siempre hay alguna trampa.

El juego utiliza toda la página cero y la memoria a partir de $0200, por lo que los vectores de ROM y muchas ubicaciones de la página cero ya están ocupados.

Para solucionarlo, adapté mis antiguas rutinas de carga y guardado para que funcionaran en este entorno tan restringido. Durante la inicialización, el área entre $90 y $CF se intercambia temporalmente y luego se restaura durante las operaciones de disco. Esto también preserva el entorno original del juego mientras se realizan las operaciones de archivo.

Sin embargo, mis primeras pruebas fueron un fracaso total. El juego se bloqueaba incluso cuando las operaciones de disco fallaban.

Más tarde descubrí la causa: había asumido erróneamente que los vectores de carga y guardado estaban en $0320 cuando en realidad se encuentran en $0330.

Tras corregirlo, el sistema de guardado y restauración empezó a funcionar.

Ahora el juego guarda automáticamente cuando recoges un checkpoint ("pez"). Cuando vuelves a iniciar el juego, carga el archivo guardado y te permite continuar donde lo dejaste. Es una funcionalidad completamente nueva para un juego tan grande y difícil.

## Recuperando los niveles originales de Spectrum

La versión original de Spectrum tenía niveles más complejos porque el Z80 podía dibujar y ordenar los gráficos isométricos más rápidamente.

Tras todas mis modificaciones, sentí que la versión de C64 era finalmente lo bastante rápida para intentar utilizar las habitaciones originales. Con los modos turbo activados incluso puede alcanzar velocidades sin ralentizaciones.

El juego ahora incluye el diseño de niveles original importado desde la versión Spectrum, en lugar de las versiones simplificadas de C64 y Amiga que se utilizaban originalmente.

Barfly/Extend probó el juego y confirmó que es posible completarlo con los niveles originales. Esto también lo convierte en la primera persona del mundo en terminar los niveles de Spectrum en un C64.

## Más errores, más correcciones y más momentos de "¿cómo demonios ocurrió eso?"

Por supuesto, nuevamente me estaba quedando sin memoria libre y todavía quedaba al menos un error por corregir y una característica que quería añadir.

La versión de C64 calculaba incorrectamente las habitaciones visitadas. Durante las pruebas, Barfly visitó más de 270 habitaciones al completar el juego, pero la pantalla de puntuación solo mostraba unas 220.

Resultó que había un error en el código original encargado de marcar las habitaciones visitadas, y ahora está corregido. Es al menos un fallo importante menos en el juego original.

También ajusté los colores para que coincidieran mejor con la versión Spectrum.

Pruebas posteriores revelaron que usar la bocina en habitaciones muy cargadas provocaba bloqueos. La solución fue sencilla una vez identificado el problema.

También encontré un pequeño error en el tamaño de algunos textos del menú y lo corregí.

Y hablando de anomalías, después de arreglar esos textos tuve que añadir una directiva `.align 2` al código fuente para evitar que el objeto trampolín se convirtiera visualmente en los gráficos de Heels.

A veces el código se vuelve como un castillo de naipes: resulta peligroso tocar cualquier cosa cuando el diseño de memoria ha sido ajustado al límite absoluto.

## Trucos y limitaciones finales

Generalmente estoy en contra de hacer trampas en los juegos, incluidos los trainers, pero esta vez hice una excepción. El menú Extend incluye una opción para activar vidas infinitas. Si se utiliza, la puntuación final no se muestra.

Originalmente, los checkpoints eran de un solo uso. Consideré que esto era injusto y modifiqué el juego para que siempre utilice el checkpoint más reciente sin retroceder a uno anterior.

Incontables horas y compilaciones fueron necesarias para llegar hasta aquí. Ahora finalmente ha llegado el momento de lanzarlo al mundo.

## Algunas notas técnicas antes del lanzamiento

Se utilizan varios trucos.

Por ejemplo, los objetos inanimados no se actualizan en pantalla en cada fotograma. Esto significa que los gráficos de los teletransportadores solo se actualizan si estás encima de ellos.

Además, si consigues dejar atrapado a un enemigo contra un objeto de manera que no pueda moverse, el juego funciona más rápido porque se omiten los cálculos de ordenación y las actualizaciones de animación para ese enemigo.

Por desgracia, si existe un objeto pez animado situado sobre una pila alta de objetos, el rendimiento puede caer notablemente. Todos los objetos de la pila deben ordenarse continuamente.

De forma similar, cuando los objetos están cayendo también pueden aparecer ralentizaciones mientras el juego calcula qué debe dibujarse y dónde.

Las transiciones entre habitaciones siguen siendo relativamente lentas porque ordenar los objetos de la habitación consume tiempo. Su orden se precalcula mediante tablas para acelerar el funcionamiento general, pero la ralentización sigue siendo perceptible.

Con mucha más memoria libre quizá podrían realizarse más optimizaciones. Sin embargo, dadas las limitaciones del hardware, esto es lo máximo que he conseguido exprimirle.

[josepzin]

Es un juego que a mi me gustó mucho y lo jugué mucho también.

Me leí todo el texto y es ESPECTACULAR lo que hizo... por dios... ojalá se haga lo mismo con otros juegos!!!

Lo he traducido y reemplacé el tuyo en inglés, Marcos. Si alguien quiere leer el original, está en el enlace a CSDb.

¡Tengo que probar esta version!

[josepzin]

Lo acabo de probar... es una mejora en velocidad TREMENDA. Ahora es muchísimo mas jugable y estuve un buen rato recorriendo el mapa, solo se ralentiza un poco en algunas habitaciones.

Que alegría de versión!

[josepzin]

El juego funcionando:
https://www.youtube.com/watch?v=Q-p9bUpom6g

[marcos64]

Nuevo megacrack del Impossible Mission 2 realizado por Grue.

https://csdb.dk/release/?id=264190



[noae]

Impossible Mission II

I wasn't able to find a crack that would load fast or work with IDE64 at
all, so I decided to take a look at it myself.

First I tried the original game from a .g64, and it seemed to load fast, but
it blanked the screen during loading. The loader also looked kind of broken
in some transitions. The game manual even says you can look at Elvin's base
while loading, but nope — the screen just closes.

Then I proceeded to look into the drive code, which I found quite
effortlessly. There was the usual obfuscation, but when you have breakpoints
available in drive memory, those kinds of things aren't really challenging
when you know what you're after.

I started reverse-engineering the drive code, which looked pretty basic. It
gets a command byte from the C64 and starts performing the requested action.
The transfer routine was optimized well beyond readability, but then again,
it was very fast.

Files are loaded directly from the floppy head. Each block contains 320
bytes of data and a 5-byte header. The code also had a lot of sync checks
during loading, which is pretty typical for certain kinds of protections. On
the C64 side, the loader only receives $f0 bytes per block. The bytes are
stored on the stack and, after the transfer is complete, written to memory.
Interleave seemed to be even blocks first and then uneven before going to
the next track.

I tried to understand how 320 bytes of data become just $f0 bytes, but I
completely lost the plot. So I decided to see how the game code handled
loading instead.

After some work with 6502bench, I found the file table the game uses and
decided to code a routine that loads the files into C64 memory and then
saves them to the IDE64 HDD. I managed to get most of the files that way,
but some behaved differently. I remembered there was a block load/save
routine, and by using that I managed to load the rest of the files. Those
blocks contained $ff bytes.

There's also some modification of the file list going on. After examining
the code, I found out that the first entry in the list has a lot of
sub-files, and the third file works similarly. It's basically self-modifying
access to the data indexes.

So I started digging deeper into the game code to understand how many of
these smaller pieces I actually needed. In the end there are $40 A-files and
8 C-files. I decided to name them from A-Z and use a suffix with a hex
number for files that use self-modified entries, indicating how they were
accessed. The result was files ranging from A-00 to A-A80 with 2-byte
spacing, giving me $40 A-files and 8 C-files.

The C-files contain the tower data. The game has 8 different towers, each
with themed rooms and graphics. A C-file contains both the data and graphics
for a tower.

The A-xx files contain all the possible rooms in the game. Rooms are
selected randomly when you start a new game, and there are more rooms
available than can fit into a single playthrough, so there's a bit of
variety.

You can also save your game, and if a save exists, the game asks during boot
whether you want to continue from it.

The high score list is saved as well if you manage to get a high score.

The file loader I implemented can load the game using both standard KERNAL
and JiffyDOS. Originally the game wanted to load under I/O, but I managed to
avoid that, allowing it to work under JiffyDOS too. The implementation takes
up more code space, and it started getting difficult to add support for save
games and high score saving because I only had two blocks available for the
loader. In the end, I managed to fit everything into those two blocks.

I couldn't get the game to start with Dolphin DOS 2, but I'm still looking
into that.

I also started to see some patterns in the room selection, so I decided to
change the RNG the game used for something better and seed it during the
intro phase with human interaction to get a different game on every load.

I found a way to trigger the Win screen and noticed that the loader died
after the end screen. It took some effort to notice that the sample player
breaks the zeropage in a way that the loader dies. So I proceeded to test my
theory: I jumped into a death, and after the sample played I hit restore to
restart the game, and the loader died again. I implemented swapping of some
zeropage locations to make the loader work. I could use the bottom of the
stack for the swap space, as the old loader used the whole stack for loading
and mine doesn't.

After the end sequence, the high score screen loads and then the game is
restarted with corrupted graphics. It was clear that the Win screen used
$d000-$dfff for the graphics and, since I preloaded the area under the I/O
space in the intro, it doesn't get reloaded when restarting the game. After
some thinking, I added the restoration of the game charsets when exiting the
high score screen, so the reloading is minimized.

Dolphin DOS 2 loading seems to work now — swapping zeropage areas did the
trick.

Added more entropy to the intro screen: while the music is playing the
random routine runs, also, when waiting for the space bar, seeding happens,
and you need to release the space bar to stop the seeding process. That
should give some human random input to the mix.

Testing with Action Replay was problematic; the game hung up after file ops.
After debugging, the cause was a running default timer IRQ. I had SEI in the
code, but it never returned from $ffd5 and got looping in the IRQ. Trurl
suggested trying to disable the timer IRQs, and that did the trick. WTF? I'm
using Exomizer on the !intro.prg — was it the cause? I naturally had my
own "file IRQ" setup from 0314/0315 $0200 so it won't conflict with the
Action Replay ROM.

Game now loads with Action Replay as well, but it's kind of slow as there
are a lot of small files to load.

Turbobit is now on in the border area of the rooms with robots for C128
users. To use it with U64/C64U, set the turbo option to Turbobit. C64 users
can enjoy the game like it originally was: a bit too slow in crowded rooms.

Elevator screen always looked broken to me because the hero walked on the
elevator sides. This was handled cleanly in Impossible Mission 1, but not in
IM2. It took some effort, but I managed to fix it cleanly. There's a sprite
on the elevator side, and it's higher priority than the hero, so it appears
on top. The sprite is generated with code, so it doesn't need any additional
memory. But the elevator has 2 exits, one to the left and one to the right,
and I only have one free sprite. So the sprite is moved to the other side of
the elevator when the player gets near it.
There's also code to swap multicolor sprite colors, and the lower map part
of the screen also uses multicolor sprites with a different palette. A
feature many of you won't even notice took some effort, but when you do
these things mainly for yourself it doesn't matter. It was important to me

The save file was larger than the amount of data it actually used, so I made
it smaller. Doesn't matter too much, but I'm currently having difficulty
making the game fit on a .d64. Fit problem was caused by me by accidentally
having file called "b" included which was real entry in the filelist the
game uses, but its not used and contained jusr pieces of the room data a-xx
files. Getting rid of the b file, all the files fit and theres even 14
blocks free on the .d64
One could wonder that why I'm not levelpacking some of the data, but the
rooms are already packed and for the extra pieces its not really necessary
as the game is slow enough already withut extra depacking time.

The game has parts of its code compiled in a way that's very difficult to
read. llm's has been helpful in deciphering some routines. Its most likely
compiled code which makes kind of sense when the original game was released
on many platform at around the same time. It also explains why some parts of
the code are so slow, like randomizing and loading the rooms at the start of
the new tower. It included depacking editing the data and packing the data
again. There not enough room in the memory to keep all of the data unpacked.
You can also go back to the rooms and if you have destroyded some robots or
blasted holes on the floors, the game can remember those. So the old room
data needs to be kept in the memory.

There seems to be a junk byte in the bots' "death beam", but I don't know if
it's a bug or not. There's no memory left for fancy animations.

When the player falls to their death, some sprites behave badly.
Fixed. This was caused by a code hard enabling all but the player
sprites which caused some anomalies when there wasnt all the sprites active
at the moment.

Bot sprites sometimes flash in rooms with lots of bots zapping at the same
time. The zapping bot disappears and reappears, which looks very buggy.
There's code that explicitly does this, but it has to be a bug. The logic is
triggered from the collision-handling code and excludes the player sprite.
The code contains a pretty wild offset-based jump table that must have come
from a compiler. No sane human would write code like this, and it certainly
didn't make my job any easier when trying to understand it.
In the end, I removed the resulting write to the $d015 register. The game
now looks clean and appears to work correctly, but more testing is needed.

Turbobit is enabled while the game randomises and generates rooms to
minimise waiting time on machines that support Turbobit control, making the
experience a bit more pleasant.

The end screen was lacking a sound effect, which was quite noticeable. After
adding one, the screen feels much more polished and "satisfying".

The game has a hard time limit of 30 minutes per tower, but you can't see it
anywhere and it's not mentioned in the manual. Under normal gameplay, 30
minutes is plenty, and most players will probably never notice it.
During development, however, I occasionally left the game running for a long
time. If it ran long enough, the hero would suddenly die and I'd be greeted
by the high-score screen. Digging through the code revealed a
30-minute-per-tower limit defined in the tower data itself. Since it's
stored in the tower data, it can be adjusted by editing the tower files.
I could disable the limit entirely in the code, but it's probably there for
a reason. So I decided to leave it as-is. Maybe there were plans for
difficulty levels where the available time was much tighter, and the fairly
generous 30-minute limit was simply left in place

Code added for improving samples on 8580, they are now audible also with a
new sid.

Added minimal infoscreen with a build number, you need press space there to
add to entropy for the rng.

DolphinDos 2 seems to have a bug where it doesnt save file address info when
saving a game, so the problem is in the dd2, not in this production.
- I added some code to get away with this, widened the save area and
poked the load address manually in, ans made the saves 2 bytes longer. It
does seems to work now but...

It seems that the z64k C128 emulator correctly handles whether the VIC-II
should output a garbage display while the system is in 2 MHz mode, whereas
x128 in VICE does not appear to.
A simple test is to enter GO64 and then POKE 53296,1. If the display still
appears normal, the emulator is likely not handling this aspect of the
hardware correctly.

Developing 2 MHz support for games has been difficult because testing often
depends on access to real C128 hardware, which is not always readily
available. In my case, testing has largely relied on a friends who owns a
C128.

The usability of the z64k emulator could certainly be improved, but it has
been extremely valuable as a development and testing tool. Despite its
limitations, it is far better than having no emulator support for this
functionality at all.


TL;DR

Converted trackloading to files
Loads now with rom based speeders, tested with:
JiffyDOS
DolphinDos
Action Replay
Should also work work with SD2IEC
Developed mainly for IDE64 but compability in mind.
Bugs fixed, details in the long text.
8580 compatible
C128 TurboBit support, also works with U64 devices with turbobit control
configured.

keys:
C=+S save on corridor/elevator
C= = suicide on rooms
run/stop = pause
restore = restart the game

[/noae]