Movimiento de sprites dentro de un scroll de chars

[SingletonJohn]

Otra buena opción es coger la rutina "desenrollada" y probar a convertirla en una rutina Automodificable. Es decir, cada 38 repeticiones del bloque, sumas 40 a $801 y lo sobreescribes. Le restas uno y lo sobreescibes a $800 y vuelves a lanzar el blucle....así 25 veces

La rutina será algo más lenta (aún así más rápida que una indirect indexed, me atrevería a decir) pero ocupará MUCHO MENOS de los 158 bytes

 
...y antes de ejecutar la rutina, tienes que volver a poner $801 en la memoria $94B-$94C y 800 en $94E-$94F (para hacer eso pondrías etiquetas). Por ejemplo

source:
lda $801,y
target:
sta $800,y


el Low byte de $801 estaría en source+1($01) y el high byte en source+2($08) (ya que las instrucciones del 6510 son de 1 byte). Lo mismo para $800 (target+1($00) y target+2($08))

[SingletonJohn]

Y si desarrollas en PC...pues te aconsejo que aprendas a manejar el C64 debugger.....es ULTRAPOTENTE y puedes ver en directo todas estas cosas

Un artículo que habla de él y te da los links de descarga

https://programacion-retro-c64.blog/2022/08/07/c64-debugger/

Usándolo, te puedo decir que el raster te pilla en la tercera línea de tiles cada vez que haces scroll....por eso se ven esas cosas raras cuando mueves bytes

[SingletonJohn]

Otra cosa que no sé si sabes @Laddh!

Algo tan inocente como esto que pongo en la imagen...lo compilo y....MIRA EL TAMAÑO. Te lo digo porque lo he visto en tu main.prg, que vas metiendo sprtiteSheet, charset, etc, en distintos lugares con la etiqueta *=

entre el LDA #4 y el LDA #5, el programa llena todo de ceros....es decir tenemos un programa de 4 bytes útiles, y el resto de los 47.107 son ceros que van a la cinta/diskette y luego van a la memoria.
Si quieres cargar cosas diferentes en diferentes bloques sin llenar de ceros todo lo de enmedio, hay que hacer varios files en binario y un loader que los  vaya cargando

[SingletonJohn]

Aquí se puede ver el archivo con la BURRADA en todo su esplendor: 47K de ceros (salvo 6 bytes)

Los dos primeros(01 08, recuadrados en morado) que es la dirección en donde va a meter el programa al cargar ($801), los dos segundos (a9, 04, que es LDA #$04).....luego un montón de ceros y los dos ultimos bytes, 47 K de ceros después (a9, 05, que es LDA #$5)

Así que OJO!!!

[Jeff]

Estos programas tipo ICU64 y el retrodebuguwr y el C64Debuguer…. No me tiran en condiciones.
Además… me parecen muy complicados para entender lo que sucede.
A veces los empleo para ver donde se van cargando los bloques de memoria, de manera visual, pero en cuando empieza a ejecutarse el programa… ya es un lío para seguimos.
Habría que hacer un programa en YouTube de cómo usarlos y sacarles un poco de jugo.

[Laddh]

Buuuffff! Que porrón de información..., tengo que releerme con tranquilidad todo el hilo y ver si lo puedo ir aplicando.
Gracias  @SingletonJohn, de verdad, tengo entretenimiento para rato 

[Laddh]

Ah! en cuanto a lo del espacio vacío entre una cosa y otra, no hay problema, se que lo voy a llenar!

[SingletonJohn]

Estos programas tipo ICU64 y el retrodebuguwr y el C64Debuguer…. No me tiran en condiciones.
Además… me parecen muy complicados para entender lo que sucede.
A veces los empleo para ver donde se van cargando los bloques de memoria, de manera visual, pero en cuando empieza a ejecutarse el programa… ya es un lío para seguimos.
Habría que hacer un programa en YouTube de cómo usarlos y sacarles un poco de jugo.

El C64Debugger lo conozco bien y es una PASADA. Pero hay que dedicarle tiempo. Coger el manual, cargar el debugger (a ser posible con programas hechos por ti o alguno sencillo) y ponerse a cacharrearlo

Ah! en cuanto a lo del espacio vacío entre una cosa y otra, no hay problema, se que lo voy a llenar!