Según lo que se ve en la imagen "boca arriba", lo que está ahi conectado son los 5V, las lineas de IO1 y R/W , y el bus de datos.
En la imagen "boca abajo", las conexiones son las de tierra, las 2 posiciones bajas del bus de direcciones, el reset y el reloj.

El conector en sí parece que sólo se conecta al socket para el chip que hubiera ahí.
Con todo eso, lo que parece es que era un chip pensado para que al leer/(escribir?) en las posiciones $DE00-$DE03 (y $DE04-DE07, etc,etc) devolviera/hiciera "algo".O sea, ocupa un espacio de 4 posiciones de memoria..
Podría ser algún tipo de dispositivo de 4 registros (con dispositivo, me refiero a cosas como el SID, el VIC, las CIAs, etc), que aparecería en ese rango de direcciones.

Asi que ese dispositivo seguramente tenía un software especifico para gestionarlo.

Chulisimo! Muy buen trabajo!

Posiblemente, todo el bucle principal del juego debería ser disparado por la interrupción...Lo anterior debería hacer el movimiento más estable, no al revés.
De la lista de cosas  a hacer en cada bucle, hay cosas que tienen un tiempo constante (leer la entrada del usuario, tocar musica), y otras que tienen un tiempo variable (mover, actualizar estado del juego) y otras que podrian ser opcionales (pintar).
Si primero haces las que requieren un tiempo constante y luego haces las de tiempo variable, puedes mirar el registro de la linea de raster, para saber si aún te queda tiempo para pintar en ese frame.
Si te queda tiempo, pintas. Si no, podrías incrementar una variable de "frameSkip".
Si al principio del bucle, "frameSkip" está,por ejemplo, a 3, durante ese bucle, sólo haces las tareas de tiempo constante, y el repintado (te saltas actualizar el mundo).
Así, aunque haya fases del juego donde hay más objetos a actualizar, o más cálculo que hacer, el juego perderá frames, o el movimiento dará un parón, pero el juego sigue "bajo control".

"Mas o menos". Si miras el código de la pi1541, está hecho programando "barebone"..No hay un operativo ni nada debajo..Porque para garantizar los tiempos que requiere un c64 real, no puedes dejar que un operativo esté interrumpiendo o priorizando tu proceso..Si no hay operativo por debajo, todo lo que quieras hacer (desde la salida hdmi, sistemas de ficheros, etc,etc), tienes que meterlo tú. Claro que hay librerias, y todo eso, pero te tienes que encargar tú de incluirlo.
Es posible que si se programase como un módulo del kernel linux, fuera más sencillo.
No es exactamente lo mismo "emular" algo, y hacer que eso "emulado" funcione con un hardware real. O sea, no es tipo "como el vice funciona en esta plataforrma, igual de fácil emulo un hardware". No pueden ocurrir "frameskips"  en un hardware real. Cambiar de estado 1 pin de la raspberry, no va a la misma velocidad que cambiar algo en memoria..
Quiero decir..imposible hacerlo?...No...Pero ni mucho menos fácil (no creas que hay tanto info sobre Raspberry pi barebone, por ejemplo). Aparte, la raspi no es que tenga muchos pines, asi que cualquier cosa que tenga que leer o escribir en los buses, olvídate.

Si algo se mueve a 3 pixels por frame, y el pintado = movimiento, puedes atravesar cosas.
Pero si lo separas,  el movimiento y las colisiones se pueden calcular varias veces por frame de repintado.
Esto lo puedes hacer en terminos de "pixeles" (moviendo 3 veces 1 pixel), o por trigonometría (intersecciones de lineas, etc), depende del caso.
Por ejemplo, en un "Pong", si la pelota se mueve 5 pixeles por frame, y en un frame determinado la pelota está a 1 pixel de tocar una de las raquetas, en el siguiente repintado hay que haber hecho la colisión, rebotar la pelota, y moverla. Para hacer eso, la posición de los objetos no se obtiene de la posición de los "sprites", sino al revés. Los "objetos" del juego se mueven, colisionan, tienen efectos, y cada X tiempo, se pintan.
Es como si en el bucle de juego, la entrada se evaluara 1 vez, el movimiento y colisiones se evaluaran X veces, y luego se pintara 1 sola vez.

Ese "bleeding" puede ser porque la señal de rojo está interfiriendo..posiblemente un problema con algún condensador..

No he tenido ocasión de comprobarlo, pero si he entendido bien en vídeos que he estado viendo, una forma de encontrar dónde hay un corto, es poner el multimetro en mostrar resistencia, e ir viendo la resistencia entre un punto que *no* deba ser tierra (por ejemplo, el pin de alimentación de cada chip), y tierra.
E ir buscando dónde esa resistencia es la mínima (que debería ser la resistencia propia de la traza).
Eso debería darte el pin que está más cerca del corto.

Lo que hay en la diskettera es un "ordenador". Es posible escribir en la RAM de ese ordenador, y lo que sale por el puerto serie es determinado por software...Así que es posible modificar el software para que lo que salga por el puerto serie sea una señal de vídeo. Esa señal de video es generada por los chips VIAs gestionados por la CPU, en vez de por un chip de video dedicado (como el VIC II), asi que la velocidad a la que puede modificar la señal es limitada.
Por eso los grandes "bloques" de blanco y negro, ya que se tiene control sobre la luminancia, y cambiar esa señal (de blanco a negro, y de negro a blanco) requiere ciclos de un reloj que va a 1Mhz...
Añadir información de color requeriría añadir una "subcarrier" a esa señal de luminancia, pero esa subcarrier tiene una frecuencia > 4 Mhz...El hardware de la 1541 no está diseñado para generar una señal a esa velocidad.