Quiero conseguir las siguientes rutinas:

Rutina 1.
Crea un una rutina que produzca un retardo, pero que sea controlable en segundos o fracciones

Rutina 2.
Hacer volcado RAM a VRAM, pero que se ejecute cada cierto tiempo. Por ejemplo que se vuelquen los sprites en una tanda, en otra se vuelquen los gráficos, etc. Al estilo de lo que hizo viejo en el Malaika.

En definitiva, lo que quiero saber es como parchear (no sé si se dice así) la memoria para que cada vez que salte una interrupcion se ejecute mi propio codigo. He estado mirando el código del ejemplo que viene en el Caruso, pero no doy de sí para entenderlo bien.

Asi, si no es mucho pedir, explicarmelo como si fuera para torpes.
Y gracias al alma caritativa que me ayude

Gracias por la rutina de tiempo, me viene de perlas.


Respecto a otra toquiero seguir preguntando. En el código de Sap, viene esto

FD9APATCHON:     ; --- PARCHEO DE LA INTERRUPCION ---
                ld      hl,FD9APATCHCODE                ; Direccion del codigo del path
                ld      [$FD9C],hl                             ; Puesta en FD9C
                ld      hl,$C3F1                                ; HL = Pop AF; JP xxxx
                ld      [$FD9A],hl                            ; Puesto en FD9A
                ret                                               ; Volvemos


pues vale, ya he cogido que lo que hace es almacenar en FD9Ch la dirección de mi codigo, pero...

esto que es lo que es
ld      hl,$C3F1                                ; HL = Pop AF; JP xxxx
ld      [$FD9A],hl                            ; Puesto en FD9A
vamos que no sé esto que es. No sé si soy claro

Y otra pregunta, en el código sustituyente, osea mi propio código, ¿ hay que tener en cuenta  algo fuera de lo normal ? o me limito a escribir mi codigo y ya esta. Lo digo por si esto de parchear las interrupciones tiene algún efecto secundario.

Y otra pregunta más. Como haceis para repartir el trabajo, poneís un contador y en función del mismo vais realizando una tarea u otra. Por ejemplo, reservo un byte de ram, y cada vez que se llame al código, voy incrementado su valor y en función de este mismo valor hago en cada llamada una tarea diferente.Lo siento pero no me se explicar mejor.

Y otra más. me daría tiempo entre llamada y llamada a volcar, por ejemplo, unos 500 bytes de RAM a VRAM.

Y ya esta de momento.
Sé que algunas preguntas ya estan más que contestadas en otros post, pero es que soy así, necesito respuestas personalizadas. y como sé que esto os lo sabeis de memoria... y si no os importa contestarme pos lo agradezco.

Y para que veaís que soy agradecido os voy a hacer un poco la bola

los de Karoshi sois fantasticos :god: :god:
los mejores msxeros del mundo  :god: :god:
que sería del MSX sin vosotros  :god: :god:

Bueno ya esta por hoy me voy a  cmptr:)

Por eso lo pregunté, a mí desde luego no se me ocurre otra forma de hacerlo. Pero no sé, a lo mejor hay formas más sencillas.

Y respecto al resto de preguntas, he cogido la indirecta. Buscaré por el foro a ver que encuentro

Eso es lo que hacía antes. Ahora el bucle de juego se basa en un autómata de estados finitos dirigido por eventos, de forma que en cada frame se deben realizar las acciones que están activadas según los eventos que han sido detectados en frames anteriores.

Lo cierto es que es muy cómodo a la hora de programar, porque te olvidas de todo si está bien hecho.

No es tan difícil. Por ejemplo tengo una acción que es "Calcular Scroll" y otra que es "Volcar Scroll a VRAM". Cada una de ellas está controlada por un bit de un byte de estado que tiene cada jugador. En un principio el bit de "Calcular Scroll" está siempre activado (aunque no siempre va a estarlo cuando termine por completo el motor del juego), con lo que la rutina de cálculo del scroll se llama 60 veces por segundo (50 en pal, pero siempre diseño en NTSC, da menos problemas). Esta rutina actualiza el scroll cada cierto número de frames (con un "cutre contador") y cuando ha calculado el siguiente scroll, activa el bit de "Volcar Scroll a VRAM". Dado que el Scroll no va siempre a la misma velocidad, no puedo saber a priori qué acciones se van a realizar en cada frame, sólo lo se cuando se han completado todos los cálculos en el frame inmediatamente anterior.

El autómata tiene una serie de estados que se encargan de activar y desactivar los bits de todas las acciones (hay unas 4 ó 5 más), dependiendo del estado en el que se encuentra y de los eventos que han sucedido.

Saludos
--
Sph.

Pues yo habia pensado hacer lo mismo para un juego q estoy haciendo. Ya q tengo una serie de eventos los cuales algunos son excluyentes y otros nacen de unos estados iniciales. Lo q pasa q mas cutre, claro.

Buena idea, si señor.

Pues estoy aprovechando esta idea de los estados para modificar una rutina que tengo, pero como llevo toda la tarde dandole vuelta y no doy con la tecla, me gustaria que me confirmarais el efecto de las siguientes instrucciones

set 3,[memoria]  -> Pone a uno el bit 3 del contenido de la direccion memoria

res 3,[memoria] -> Pone a cero el idem

bit 3, [memoria] -> produce Z=0 si el bit 3 esta a uno y Z=1 si el bit 3 esta a cero

vamos que si hago esto

set 3,[memoria]
bit 3,[memoria]
call z,rutina

debería saltar a la rutina ¿verdad?

me vale un si o un no. Es para descartar errores.

 


Bueno gracias por la aclaración, si soy sincero es la primera vez que uso las instrucciones de manipulación de bit y me he hecho un poco de lio

Voy a probar mis nuevos conocimientos a ver que tal.