Para hacer que se hablen las placas entre sí, estar manejando la placa del cartucho, que está soldada con cablecitos (y para el cartucho..son muchos cablecitos..), pedí una PCB...y ya ha llegado! Aqui se ve mejor cuál es mi idea: usar directamente placas "off the shelf", conectarlas a la PCB, y listo, sin soldar componentes SMD. Por un lado, simplifica el construir el dispositivo, ya que sólo hay que soldar el conector de la placa (simples pin headers hembra), y listo. Por otro lado, el conjunto queda más grande de lo que debería. Ésta placa es sólo para el cartucho, para facilitar el desarrollo. La placa final debería incluir al menos un ESP32, y una teensy 4.1, por lo que es necesario más espacio, pero la idea inicial es la misma: que simplemente haya que conectar la placa a la PCB. En una segunda fase, se podría hacer una PCB optimizada con todos, o muchos de los componentes soldados directamente a la PCB, lo que reduciría mucho su tamaño.

Claro, es a lo que me refiero. Los freezeos se graban en disco, porque son datos, y en la época, los datos sólo se podían guardar en disco...Ahora se podrían guardar en la SD, o en la memoria flash del micro. Pero habría que rehacer el cartucho del freezer.
Mirando la documentación de los snapshots del vice (https://vice-emu.sourceforge.io/vice_9.html#SEC283), se ven los "modulos" que escriben su estado en un snapshot.

MAINCPU   6502   The Main CPU - although it is a 6510, only the 6502 core is saved here
C64MEM   Memory   Holds the RAM contents of the C64. Also the CPU I/O register contents are saved here.
C64ROM   ROM images   Dump of the system ROMs
VIC-II   656*   The VIC-II of the C64/128
CIA1   6526   The CIA for the interrupts and the keyboard
CIA2   6526   The CIA for the userport, IEC-bus and RS232.
SID   6581   The SID sound chip of the C64/C128
REU*      The RAM Extension Unit state (optional)
ACIA1   6551   An ACIA (RS232 interface) at $DE00 (optional)
TPI   6525   A TPI at $DF00 for a parallel IEEE488 interface (optional)
*   Drive modules   The emulated drive(s) have their own modules see section 9.2.1.6 Drive modules

Restaurar el estado completo de una máquina real no es sólo leer la memoria, y volverla a escribir. Por ejemplo, restaurar la máquina a exactamente la misma línea de raster en la que se encontraba
en la captura puede ser importante...Cuando hay dispositivos mapeados en memoria (el VIC-II, el SID, las CIAs), pueden tener estados internos (por ejemplo, el punto de ADSR en el que se encuentra una nota en el SID), valores de sólo lectura, posiciones que al leer, lees un registro diferente que cuando escribes...
Y todo eso, sin contar con fastloaders cargados en la propia diskettera, que es un ordenador aparte, y que el cartucho no puede "congelar".

En la época, se sacaba un cartucho freezer que a lo mejor funcionaba con el 80% de los juegos, y listo. Hoy en día, si sacas eso, tienes un github lleno de gente quejándose de que el cartucho, cuando se usa en la fase 10 del juego X, no funciona.
Depurar ese tipo de cosas es muy muy tedioso...Vamos, yo no me metería a hacer eso..

El cartucho (o, mejor dicho, el "cacharro", porque son más cosas) en el que trabajo...Es sólo una forma de pasar tiempo con el C64 como otra cualquiera..Cuando empiece a funcionar como quiero, publicaré el código, pero mi intención no es (para nada) diseñar una placa fácil de replicar y ponerme a soldar placas para vender...No me interesa eso.. Píllate una ultimate ya :-D.
El test que me funciona es precisamente enviar CRTs por bluetooth desde un explorador en el móvil, pero no de la forma en que quiero que ocurra. Ahora funciona con una conexión directa entre el cartucho y el movil. Lo que quiero es que el movil se conecte a una placa, que redirija los comandos al cartucho, a la diskettera, a la cinta, o a lo que sea que puedas tener conectado.
Esa misma placa, me sirve para que emule la cinta, y es en lo que estoy, cuando el nuevo curro me deja algo de tiempo :-P

No es posible hacerlo con la pi1541, o con cualquier otro emulador de disco. Lo único que puede hacerlo es un cartucho.
Guardar o cargar el estado del C64 require poder acceder a su memoria. El puerto serie no tiene, por sí msmo, esa capacidad. De la misma forma que poner un pendrive en un ordenador no hace nada por sí mismo.
Lo que se conecta por el puerto de cartucho, en realidad se convierte en una extensión de la placa del c64. Está conectado al bus de datos y direcciones,además de otras líneas de control. Usando una de estas líneas , la de DMA, un cartucho puede detener al procesador, y tener acceso de lectura/escritura a toda la memoria del c64 (cargar o salvar estado).

Lo que no entiendo muy bien es lo que dices de "tengo 3 pantallas", cada una con su propio comienzo.
Cuando he implementado scroll, yo he montado un "mapa". Un mapa con scroll puede tener perfectamente 3 pantallas y media de ancho, y tiene 1 único comienzo en memoria.

En total, el mapa es de X caracteres de largo por Y de ancho (que no tiene por qué significar X*Y bytes, pero por simplificar..), y si tienes una rutina que dado un desplazamiento en X y en Y de la esquina superior izquierda de la pantalla con respecto al mapa (con X e Y en píxeles), sabe pintar la pantalla completa, no deberías tener problema en desplazar a la derecha o a la izquierda.

Si, además, el mapa está compuesto de tiles,y el mapa es de X*Y tiles, el X e Y de la esquina superior izquierda pasa a estar en coordenadas de tile + offset X e Y dentro del propio tile. ( por ejemplo, al comienzo, el tile que está en la esquina superior izquierda, tiene coordenadas 0,0 en el mapa, y el offset de tile es 0,0. Si el mapa hace scroll de 2 caracteres, y el tile es de 4x4, la esquina sigue siendo el tile 0,0, con offset 16,0 (en píxeles). Cuando hace scroll de 4 caracteres, el tile es el 1,0 con offset 0,0, etc.

Lo que me resulta más complicado son las distintas formas de activar el scroll. O sea, cuándo y cómo "mueves la camara". En el video de Robocop, hay una especie de "caja" donde se mueve el personaje, de la cual no sale (excepto en los extremos del mapa). El personaje "empuja" la cámara cuando llega al borde de esa caja, y así activa el scroll, que se hace a velocidad constante.

Pero si miras por ejemplo el Sams journey, el scroll sigue al personaje con un retraso, y con una velocidad variable. Por hacer un símil, es como si el personaje tirara de la pantalla con un elástico que llevara atado a la cintura. Es un movimiento que tiene una aceleración, no es una velocidad constante.

 

KFF se usa para emular cartuchos, no discos. Lo que ocurre es que hay discos que es posible convertirlos a cartuchos (y es de donde sale tanto cartucho que hay por ahi). Básicamente, se extrae el programa del d64, y se convierte a un .crt, como si fuera una ROM. Eso normalmente requiere que el juego sea de 1 sola carga, y que no toque el disco para nada que no sea cargarse (sin soportar multicarga, escritura en disco, proteccion anti-copia, etc,etc).

Un disco tiene un motor que no siempre va a la misma velocidad, por temperatura, fabricación, etc,etc. Por eso, la codificación de bytes en un disco utiliza su propio protocolo (GCR), hay algoritmos para detectar la velocidad de rotación, etc,etc. Todo esto está en el kernel de la diskettera, que tiene su propio procesador para ejecutar el código de ese kernel, decodificar GCR a través de una CIA,  convertirlo a bytes, y enviar esos bytes usando el protocolo IEC al C64. El protocolo también soporta que el C64 envíe a la diskettera código, para sustituir las rutinas de lectura por defecto (fastloaders).

Mientras la U1541 y la pi1541 emulan todo eso (es decir, cogen un d64, convierten los bytes a la codificacion GCR, y emulan a nivel del cabezal de la diskettera pasando por encima de cada trozo del disco, incluyendo ruido aleatorio, emulando la CIA, la ROM, el procesador...), una SDIEC coge un d64, y envia el contenido del disco directamente al C64, emulando sólo el protocolo IEC, y algunos fastloaders más que están pre-programados.

Para emular todo lo que hace una U151 o la pi1541, se necesita un cacharro mucho más rápido que para sólo emular el IEC. Pero deberían soportar todo tipo de protecciones, fastloaders,etc,etc.

Por fin! Primer upload del teléfono al cartucho, por bluetooth!
https://www.youtube.com/shorts/and0fWYy-5Y

Como se ve, la aplicacion del movil es aún la básica generada por el Android Studio...No hay mucho más hecho que el emparejar por bluetooth, y el explorador de ficheros locales, con soporte para ficheros zip.
La transferencia es aún muy lenta. Esto se debe a que estoy usando un ESP32 como "proxy" bluetooth (conectado por el puerto serie al STM32, y por bluetooth al telefono). Este programa está hecho con código Arduino, y la API bluetooth de este framework tiene sus limitaciones con ESP32. Haciendo una aplicación nativa se aumentaría mucho la velocidad.
Por otro lado, el ESP32 está conectado al STM32 con cables dupont de los chinos, por lo que empieza a dar problemas en cuanto se sube mucho la velocidad del puerto serie.
Ambas cosas, cuando me ponga a hacer la placa, no serán problema, por lo que debería recibirlo casi instantáneamente.
Aún queda mucho trabajo que hacer, ahora mismo está todo cogido con pinzas, pero haber superado los problemas de empezar a trabajar con Android, y las muchas sorpresas que me había guardado el puerto serie del STM32...

Juer...con tornillos largos que atraviesen la carcasa y la placa...que calentar esa tuerca para que el estaño se le pegara, habrá costado lo suyo, en tiempo, y en estaño :-P