Puede ser que el casquillo que conecta las pistas superior e inferior de ese conector esté roto o haya desaparecido.

Cuando me pasa eso, aumento un poco el diametro del agujero y paso por él dos hilos de cobre trenzado (los saco de un cable cualquiera) y la parte que va a quedar escondida o pisada por la pieza , la sueldo a la pista que le corresponde lo más apartada posible de ese conector antes de ponerlo encima. Incluso puedes "aplastar" ese hilo trenzado con unas alicates de "picopato" para dejarlo lo más plano posible.

De esta manera me aseguro de que el contacto esté en ambos lados.

Aclarar que lo de apagar y desconectar las IRQ de colisiones no está completo.
Las IRQ de raster las envio a una rutina de movimiento y las de sprites a la rutina de comprobar colision.
Se puede hacer comprobando los bites de $D019, pero me gusta experimentar XD

Acabo de hacer unas pruebas con sprites y las colisiones.

Como comenté más arriba, desplazo varias veces los sprites durante un refresco de pantalla para así poder acelerar el ritmo del juego. Es un simple bucle contador.

Si la velocidad de movimiento (pixéles desplazados) no excede del tamaño de la bola (6 pixéles) , me reconoce todas las colisiones sin problemas.

Naturalmente, si a la vez estas desplazando el otro sprite con que colisiona (un pad o barrera de 2 pixeles de grueso por 22 de largo) , la suma de ambos consigue que se cuele entre esos 2 pixéles sin detectar colisión. Sí me detecta colisión con otro sprite que tengo justo debajo del pad haciendo de cuerpo.

Como desplazo la bola 1 pixél por cada 2 que se desplaza el pad, la velocidad máxima (pixeles desplazados) que puedo poner está entre 8 o 10. Contra más pixeles desplace la bola, mayores probabilidades de que aparezcan fallos en la detección.

Por las pruebas que he hecho, no detecta las colisiones hasta que no pasa el barrido por la pantalla, o eso parece.
Borrando la bandera de colisiones justo al entrar (con una colisión sprites activada) a la rutina de movimiento fuera de pantalla y leyendola de nuevo al finalizar , me da 0 colisiones (raster aún fuera de pantalla visible) a pesar de que ha habido colisión.

Una vez ya ha mostrado la pantalla, detecta la colisión.
 

Te comprendo perfectamente.
Si solo chocan 2 sprites, no hay problema, pero con 3 ya es cuando hay que usar las coordenadas o te volverás loco.
Probe a desconectar los sprites no deseados y volver a comprobar colisiones y otras ideas que se me pasaron por la cabeza. Nada funcionó como me hubiera gustado.

Como estoy con un juego tipo Arkanoid, tocar el PAD con forma curvada es esencial, así que opté por evitar que otros sprites se tocasen entre ellos y a correr. Así no me ha fallado de momento, seguro que cuando lo ponga a prueba más a fondo la bola se enganchará en el pad cambiando de sentido sin fín o atravesará el pad... cruzare ese rio cuando llegue XD

Qué curioso, ayer me estuve comiendo el tema de colisiones con sprites.

Una de las características que tiene es que cada vez que haces una lectura en la dirección de las colisiones, estas se resetean y por eso, si haces dos lecturas seguidas, la segunda da 0.
Lo que hice fué guardar el valor de la primera lectura en una "variable" y entonces trabajar con ella.
Como uso interrupciones para temas de movimiento, he usado las mismas interrupciones para que me detecte barrido o sprites dependiendo del código que se esté ejecutando.
Cuando entro en la rutina "activada" por raster ,donde muevo y muestro los sprites (varias veces del tirón por tema de velocidad/dificultad del nivel del juego usando un bucle), conmuto entonces a interrupciones por colision sprite/sprite y desvio a otro bloque si hay colision.
Una vez salgo de la rutina del raster, desactivo las interrupciones de sprites y activo la de raster ya que no va a moverse nada hasta que entre de nuevo.

Lo de coordenadas está bién por que puedes hacer que los sprites puedan "rozarse" sin que te maten XD, pero te obliga a usar sprites casi cuadrados.

Como en mi caso estaba usando un sprite arqueado, este método detectaria colisión sin tocarse en los extremos y se veria raro.

En teoria deberia poder hacerse con dos comprobaciones, como pintar un cubo en pantalla. Coordenadas orígen y coordenadas destino. Ahora me vas a tener pensando en ello todo el día... maldición 

Commodore Computer Club numero 3.

Esta completa a excepcion del fichero de datos del programa Divisas. No es un PRG sino algun tipo de fichero de datos parecido (creo) a los SEQ. Carga bien desde el programa Divisas pero no consigo leerlo independientemente para despues grabarlo a la unidad de discos. Es un programa de los que hay que cargar con OPEN... segido de GET# o LOAD# o algo asi.Siempre tuve este tipo de ficheros atravesados y parece que la maldicion continua    Si alguien sabe con hacerlo que lo diga ahora o calle para siempre...

No tenias el 1541 u2?. A esta le da igual , salvas el bloque del programa y datos juntos .

Esos ficheros se leen de forma secuencial.
A cada GET, lee datos de la cinta, no carga "del tirón".

Hay que leer hasta encontar el final de los datos, pero hablo de memoria de algo que hice hace la tira de tiempo.

Fantastico!!!!.
Impaciente espero.