Si no te quieres complicar la vida con las coordenadas, y puedes sacrificar un poco de suavidad en el movimiento, podrias usar en los sprites coordenadas de pixel doble, ya que por lo general los juegos suelen usar el modo multicolor de 160 puntos.
Lo que tendrias que hacer es guardar las coordenadas X de cada sprite en una posicion de memoria, y periodicamente actualizar eso en los registros del VIC, previamente multiplicando por 2 estas coordenadas. Para esto, usas la instruccion ASL, que corre a la izquierda los bits del parametro, en este caso la "variable" donde guardas la coordenada X del sprite. Esta instruccion, a diferencia de ROL, coloca automaticamente un 0 en el bit 0 (ROL coloca ahi el valor de carry), y el bit 7 que se pierde se copia a carry, por lo que despues deberias colocar el valor de carry en el bit mas significativo de la coordenada X en el registro correspondiente del VIC para ese sprite.
De esta manera al mover el sprite incrementarias 1 pixel, pero al actualizar a traves de esa rutina se incrementarian 2, internamente tu manejarias coordenadas de 0 a 159, pero en la pantalla manejarias de 0 a 319, avanzando de a 2 puntos.
Solo tendrias que tener en cuenta que para leer las coordenadas X desde el VIC deberias dividir por 2 si quieres obtenerlas tambien en un rango de 0 a 159, esto lo harias con la instruccion ROR, que rota el parametro hacia la derecha, colocando en el bit 7 el valor de carry, y el bit 0 perdido en carry, por lo que primero deberias leer el bit mas significativo de la coordenada X de ese sprite desde el VIC, y colocar este valor en carry, luego usar ROR con el registro de coordenada X de ese sprite (para dividirlo por 2 incorporando carry en el bit 7), y en carry te quedaria el bit 0 que ya no te importa.

     En el proximo proyecto he empezado a mover Scrolls por primera vez, es verdad que lo hago de una forma sencilla y primitiva pero bueno,..estoy empezando con ésta tecnica,..ya los tengo construidos, mostrados y se mueven y todo va bien,..pero la tecnica que he usado me ha supuesto un despelote de bytes tremendo que pienso que tiene que haber alguna forma de economizar, por mas que prueblo bucles no doy con la solucion...

No me puse a analizar demasiado el codigo pero interpreto que estas experimentando con scroll por hard, y que cada 8 puntos, o 4 o lo que convenga, haces scroll de caracteres, o que directamente lo haces de a caracter, es decir 8 puntos (o 4 en multicolor) a la vez.
No se si se puede compactar mucho el codigo, pero me parece limitado, porque no tienes libertad para imprimir lo que quieras, al usar INC o DEC necesitas tener la definicion de los caracteres contiguos en memoria. Lo ideal seria que pudieras imprimir la linea que fuera con cualquier combinacion de caracteres y tener una rutina generica para hacer scroll.
Simplificando un poco la cosa, si tuvieras una linea de 5 caracteres y sus posiciones de memoria fueran A, B, C, D y E, imprimirias la linea de 5 caracteres con lo que se te ocurra, y luego en cada paso del scroll harias:

Leer A y guardarlo en una "variable" X
Leer B y escribirlo en A
Leer C y escribirlo en B
Leer D y escribirlo en C
Leer E y escribirlo en D
Leer X y escribirlo en E

Eso se podria generalizar para cualquier linea usando algun puntero o indice, primero se guardaria el contenido de la posicion actual de memoria, que deberia ser el primer caracter de la linea, luego se haria un bucle que repitiera N-1 veces (N es el ancho de la pantalla en caracteres) el proceso de leer la siguiente direccion de memoria y guardarla en la actual, para luego incrementar el indice apuntando al siguiente caracter. Por ultimo, habria que volver e leer el primer caracter guardado, y colocarlo en la direccion de memoria actual, que a esta altura deberia ser el caracter mas a la derecha de la linea. A esa rutina solo tendrias que darle como parametro la direccion inicial de la linea, y cargar el indice, por ejemplo el registro X, a 0. Tambien deberias reservarle un byte de memoria para guardar temporalmente el primer caracter.
La misma rutina despues se puede usar para el scroll por pixel, pero en ese caso deberias trabajar en 38 columnas, para eliminar el parpadeo en los bordes.
   

$E50C seguramente es la misma rutina que puse al final, no mire el desensamblado de la ROM pero probablemente esta entrando directo saltandose la parte en que chequea el valor de CARRY para decidir si lees o ajustas la posicion del cursor, porque la entrada original es $E50A. La entrada correcta (para que sea compatible con todos los modelos de Commodore) seria $FFF0, pero como esta ROM no tiene una rutina para imprimir un cadena, y estas usando una del BASIC, no tiene mucho sentido mantener compatibilidad, ya que el BASIC difiere en los distintos modelos.

Lo decia porque sigues un camino un tanto inusual, te has salteado algunos pasos en tu incursion en la programacion en ensamblador, normalmente lo primero que se aprende despues de las instrucciones del 6502 son las rutinas de la ROM, lo que vendria a ser la "BIOS" del C64.
En la mayoria de los ordenadores el uso es similar, se definen dispositivos asignandoles un numero, algunos son de entrada, otros de salida y otros de entrada/salida, un ejemplo de dispositivo de entrada es el teclado, de salida la pantalla, y de entrada/salida todo lo que tiene que ver con el almacenamiento. En los Commodore (PET, C16, Plus/4, C128, C64, etc.) se usa la rutina OPEN para abrir un canal hacia un dispositivo (que puede ser el teclado o la pantalla tambien), y luego hay rutinas para enviar o recibir un byte, dependiendo del dispositivo del cual se trate, se requerira llamar a otras rutinas antes de OPEN, por ejemplo si es un dispositivo de E/S hay que llamar a una rutina para especificar el nombre del archivo. Si se quiere enviar un comando a la disketera, como por ejemplo para formatear un diskette, se usa la cadena de comandos como si fuera el nombre de archivo.
Usando el numero de dispositivo de la pantalla se puede imprimir con esas mismas rutinas genericas, pero la que usaste es una rutina que enmascara todo eso y va directamente a la pantalla, aunque por debajo use las genericas.
Lo bueno de las rutinas genericas es que aprendiendo como usarlas luego haces de todo con casi el mismo codigo, solo cambiando la forma en que las usas.
Hice una busqueda rapida y aqui sale algo de las rutinas, un poco resumido:
https://www.c64-wiki.com/index.php/Kernal
Aqui detalla un poco mas el uso de cada rutina:
http://sta.c64.org/cbm64krnfunc.html
En el caso especifico de la posicion del cursor (la rutina que usaste, CHROUT, que tiene el vector de entrada en $FFD2 en todos los modelos de Commodore, imprime en la posicion actual del cursor), se ajusta o se lee usando la rutina PLOT:
PLOT   $FFF0   65520   Set or retrieve cursor location
https://www.c64-wiki.com/index.php/PLOT
Lo que no recuerdo es que registro contiene la fila y cual la columna, en esos dos sitios dice exactamente lo contrario en cada uno, ese ultimo que puse dice que X contiene la fila e Y la columna, el otro dice lo contrario, y me parece mas logico, X: columna, Y: fila.
"$FFF0   PLOT. Save or restore cursor position.
Input: Carry: 0 = Restore from input, 1 = Save to output; X = Cursor column (if Carry = 0); Y = Cursor row (if Carry = 0).
Output: X = Cursor column (if Carry = 1); Y = Cursor row (if Carry = 1).
Used registers: X, Y.
Real address: $E50A."
Justo antes de llamar a PLOT necesitas ajustar el valor de CARRY, en eso coinciden los dos sitios, si CARRY=0, al llamar a la rutina lees la posicion actual del cursor, que se carga en X e Y, si CARRY=1, necesitas cargar X e Y previamente con columnas y filas validas, y al llamar a PLOT deberia cambiarse la posicion del cursor usado por CHROUT.
Estuve buscando y no los encontre escaneados, pero puede ser que esten en alguna parte, si los encuentras te recomiendo estos libros, no son muy extensos pero tienen buena informacion, solo tengo el ultimo, el primero debe ser mas interesante en tu caso porque trata de graficos y sonido. En este tema de retrocomputacion se hablo de estos libros: http://www.retrocomputacion.com/e107_plugins/forum/forum_viewtopic.php?34771
Fijate que trae una tabla (la segunda foto que aparece) donde se explica bien el uso de cada rutina de la ROM.

Me parece que el 1902A tiene ademas RGB analogico, al estilo de los 1084 (que tienen los dos tipos de RGB), el 1902 solo acepta RGBI (digital) como el que se usa en C128.

Igual es un cable muy facil de armar, si no recuerdo mal es 1 a 1, el pin 1 con el 1, el 2 con el 2, y asi.

Para emular "por hard" hay que conocer el circuito mucho mejor que para hacerlo por soft, siempre hay que hacer ingenieria inversa para los circuitos que no se conocen del todo bien, o que tienen un comportamiento que no es igual en todos los chips, como en el caso del SID. En un circuito con FPGA los tiempos tienen que ser exactos porque se hace todo en tiempo real, en un emulador por soft no, por ejemplo hay emuladores que aprovechando que solo se generan 50 imagenes por segundo, hacen todo el proceso entre dos cuadros "al instante", justo antes de renderizar el cuadro. Es decir que no procesan las instrucciones del 6510 en tiempo real, sino que antes de dibujar el proximo cuadro, ejecutan aceleradamente todo lo que ocurrio entre el cuadro anterior y el actual, asi que los tiempos mas o menos se pueden ir corrigiendo por soft, mientras que en FPGA si uno agrega un componente de mas, alguna señal puede llegar despues de lo que deberia (porque cada componente agrega un retraso), y empezar a funcionar todo mal.
En un emulador por soft, como los componentes son virtuales, digamos que se puede hacer trampa para compensar, pero por supuesto requiere un hard mucho mas complejo.
La ventaja de usar FPGA hasta ahora era la portabilidad (por portatil) y el bajo consumo, pero con una Raspberry Pi ahora eso se esta emparejando un poco con la emulacion por soft.

Creo que lo que hizo fue resucitar un proyecto de hace mas de 10 años, cuando las tarjetas flash no eran tan grandes, hoy no tiene sentido usar un disco. Si lo tendria por ejemplo en Amiga, ya que todavia las tarjetas flash son caras para los tamaños necesarios para contener todo lo que uno quisiera grabar. Y aparte del tamaño, tambien esta el asunto de la cantidad de escrituras, aun cuando haya tarjetas del tamaño adecuado a buen precio, si se usa por ejemplo en PC para correr Windows, las tarjetas flash durarian poco tiempo porque el sistema escribiria mucho, en Amiga no es tan asi pero tambien seria algo a tener en cuenta si se escribe mucho al disco.
Pero en C64 se puede decir que practicamente el contenido de la tarjeta es estatico, ya que cuando se escribe por lo general es para agregar nuevos programas y no para modificar algun archivo existente, por lo que una tarjeta flash es suficiente.