Hay que tener en cuenta que esta forma de codificar es muy limitada, por ejemplo, no permite poner musica durante el juego, o por lo menos no sin interferencias entre las dos rutinas, y una cosa que es mas evidente, mientras se ejecuta el salto los enemigos y el resto del codigo del juego quedarian congelados.
Nunca hice un juego en C64, pero me parece que lo normal es tener variables y banderas de estado, y poner todo el codigo del juego en la rutina de interrupcion que se llame una vez por cuadro (50 o 60 veces por segundo). Lo ideal es que el codigo comience a ejecutarse una vez que empieza el borde inferior de la pantalla, para tener la mayor cantidad de tiempo de ejecucion libre de interrupciones del VIC. Luego puede ser que uno agregue codigo que se ejecute durante el dibujado de la imagen, o durante el borde lateral, pero eso ya depende de cada juego.
Lo que se haria es basicamente renderizar la imagen justo antes de que se dibuje cada cuadro, por lo que en este caso particular habria que chequear una bandera para saber si estamos en un salto, y tendriamos un contador que nos dice en que paso del salto estamos, que podria traducirse como en que cuadro de animacion del salto estamos. Se podria tener una tabla en X y en Y con las diferencias de coordenadas a sumar o restar al sprite, por ejemplo digamos que el salto tiene 20 cuadros, hariamos una tabla donde en el paso 1 (el paso 0 es la posicion original) podriamos poner 2,2 (significa que si estamos en el paso 1, sumamos 2 en X y 2 en Y a las coordenadas del sprite), en el paso 2 podria ser 3,2 (avanzamos 3 en X y 2 en Y), y asi con los 20 cuadros. Cuando llegamos a la rutina de interrupcion, preguntamos si estamos en un salto, vemos el numero de cuadro en una variable, y segun ese numero saltamos a la posicion correspondiente de la tabla (se puede usar el registro X o Y para acceder a la posicion de memoria del elemento por direccionamiento indirecto). Leemos los valores de la tabla y sumamos las coordenadas (se puede tener dos tablas para X e Y, o colocar pares de coordenadas en la tabla), luego incrementamos en 1 unidad el numero de cuadro del salto, si llegamos a 20, apagamos la bandera que indica que estamos en un salto.
De esta manera se hace todo en multitarea, no frenamos el resto del codigo mientras ejecutamos el salto, y ademas al tener una tabla, podemos hacer saltos bastante elaborados, incluso acrobaticos. El refinamiento que le quedaria a eso es hacer que el salto sea mas lento, porque puede ser que el personaje se quede mas de un cuadro de imagen en la misma posicion, y no tiene sentido andar repitiendo coordenadas. Lo que se podria hacer es agregar un contador extra que decrementamos luego de procesar un cuadro del salto, si este contador llega a 0, ahi recien decrementamos el numero de cuadro del salto. Por ejemplo podriamos bajar la velocidad del salto a la mitad, esto es que cada 2 cuadros de imagen se avanza un cuadro de la animacion del salto. Lo que hariamos es preguntar si estamos en el salto, si es asi, buscamos el numero de cuadro del salto, sumamos las coordenadas como ya vimos, y luego decrementamos el contador de velocidad de salto, que vale 2 y pasa a valer 1, como no llego a 0, aqui terminamos el proceso del salto. En la proxima interrupcion de video, otra vez procesamos el salto como ya lo hicimos, y las coordenadas van a ser las mismas, porque no avanzamos el numero de cuadro del salto, luego decrementamos el contador de velocidad del salto, que era 1 y ahora pasa a ser 0, como es 0 esta vez si incrementamos el numero de cuadro del salto (por lo que en la proxima interrupcion si van a cambiar las coordenadas), y ponemos el contador de velocidad del salto a 2 nuevamente. De esta manera cada par de coordenadas de la tabla se va a repetir en 2 cuadros de imagen y la velocidad del salto es la mitad.