Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Dashiad

Páginas: 1 2 [3] 4 5 ... 11
31
General / Re:Hardware nuevo para C64
« en: Agosto 02, 2022, 13:27:35 »
Eep, no conocía la DD001...Pero, como dices, es compatible con IBM...no con CBM.
El problema siempre con las disketteras de Commodore es que, son ordenadores, con su procesador, su memoria, su ROM...La mayor parte del software, lo que hace es simplemente leer y escribir a disco, y todos esos detalles no le interesan. Pero hay software que sí que hace uso de ese hardware "extra" que hay en la diskettera de commodore. Eso no va a funcionar en una diskettera "tonta" (o un sdiec,etc).
Entiendo que esa diskettera, para tus datos propios, para juegos de carga única (lo que es equivalente a la conversion d64->.crt), puede funcionar...Pero no sería compatible con el 100% del software de C64.

Una diskettera IBM no puede hacer esto (y la 1541 no debería hacerlo, y ser mas ráaapida):
https://www.youtube.com/watch?v=zprSxCMlECA

32
General / Re:Hardware nuevo para C64
« en: Agosto 01, 2022, 23:14:15 »
No sé exactamente a qué te refieres con acceder a los bancos de memoria  como se accede a los diskettes... Los cartuchos no tienen un "sistema de ficheros", sólo tienen ROMs.. Es posible leer las roms, cambiar el banco activo si el cartucho lo soporta, etc,etc.

Sobre la diskettera y el cartucho, lo veo complicadillo...En todo caso, sería por el mismo puerto de diskettera, pero posiblemente el cacharrito que fuera necesitaría ejecutar ROMs de la 1541 modificadas, ya que gestionan la codificación de los bytes en el disco, y no sé (no creo) si es la misma codificación usada en las disketteras normales..Vamos, un jaleo de mucho cuidado..

33
General / Re:Hardware nuevo para C64
« en: Agosto 01, 2022, 12:48:38 »
Hay una utilidad que "convierte" ficheros .d64 a ficheros .crt, y el tipo de cartucho de ese crt, permite cambiar los bancos de memoria mapeados a los 16Kb del cartucho.
O sea, que no es un "emulador de diskettera", sino que convierte, en lo posible, un .d64 a un cartucho.
Cualquier cosa que sea propia de una diskettera (multicarga, fastloaders, etc,etc), no va a poder hacerlo.

Pero sí que he leído (y se menciona en un video reciente de varios trabajadores de Commodore, https://www.youtube.com/watch?v=8cvu_iRvM-Y), que sí que había una diskettera que funcionaba a través del puerto de cartucho.
En cualquier caso, para emular la diskettera a precio barato, la Pi1541 es lo mejor que hay. Puedes meterla incluso en una raspberry pi zero.

34
Yo si que los he tenido que cambiar alguna vez..También el que se usa para el datasette.
Pero como dices, no cuesta casi nada cambiarlos.

35
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Mayo 17, 2022, 15:50:55 »
Quick update:
Aunque el curro me está tomando mucho tiempo estos ultimos meses, lo que se ha ido trabajando es en algo menos interesante, que es toda la mensajería para conectar el stm32 vía bluetooth al teléfono.
La idea es que no sólo éste, sino cualquier otro dispositivo, se pudiera conectar al mismo UI del teléfono. Podría haber conectados X dispositivos. Uno de ellos hace de "master", que es el que está conectado al teléfono. Tanto el master, como el resto de dispositivos, envían mensajes indicando qué tipos de fichero gestionan, qué dispositivo emulan, qué opciones tienen, etc. Todo esto tiene que llegar al teléfono, y que se construya el UI para cada cosa. El teléfono, a su vez, envía comandos a los dispositivos ("carga este fichero", "para", "reset", etc).
El problema es que el stm32h7 no tiene bluetooth, asi que por ahora estoy usando un bluetooth externo (el típico hc-05).
Asi que...seguimos en ello.

36
Desarrollo / Re:Pi1541 y Tapuino en 1 solo dispositivo
« en: Febrero 20, 2022, 17:48:04 »
Me autorespondo... Según otro documento de skoe, absolutamente alucinante:
http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf, la ecuación de la PLA para el pin ROMH es:
Citar
-- # HIRAM = 1 ,
-- address $A000 .. $BFFF ,
-- no VIC access , read , cartridge : 16k
p21 <= n_hiram and a15 and not a14 and a13 and not n_aec and rd and not n_exrom and not n_game ;

-- address $E000 .. $FFFF ,
-- no VIC access cartridge : Ultimax
p22 <= a15 and a14 and a13 and not n_aec and n_exrom and not n_game ;

-- VADDR $3000 .. $3FFF , $7000 .. $7FFF , $B000 .. $BFFF or
-- $E000 .. $EFFF ,
-- VIC -II access , cartridge : Ultimax
p23 <= va13 and va12 and n_aec and n_exrom and not n_game ;
Si cualquiera de esas 3 condiciones es cierta, ROMH (que es lo que llamaba "pin HIRAM")  estará activo.
Y de esas tres, ROMH sólo depende del bit HIRAM, en el primer caso.
En los otros dos, cuando está activo el modo Ultimax, el pin HIRAM (ROMH) siempre está activo (a 0V), independientemente de lo que haya en el bit HIRAM.
Así que, para saber lo que hay en HIRAM es necesario que se produzca el primer caso (cartucho de 16K).

37
Desarrollo / Re:Pi1541 y Tapuino en 1 solo dispositivo
« en: Febrero 20, 2022, 15:22:31 »
Siempre que veo este tipo de movidas me pregunto si los ingenieros que diseñaron estos equipos tuvieron en cuenta estas cosas o es pura casualidad que se pueda hacer todo esto usando lo que hay.
Los mapas de memoria estaban diseñados así, y estaban documentados en los manuales. Yo supongo que a los ingenieros electrónicos pensar en ese tipo de cosas es algo "natural", igual que a un ingeniero de software lo es pensar en un diagrama de clases, por decir algo.

Es posible implementar esa sobreescritura del kernel, viendo tooodo lo que hay que hacer en 1 solo ciclo de reloj? KFF no puede, eso seguro. EF3, Ultimate, etc, usan FPGA/CPLD, y aún así, posiblemente vayan muy justitas para hacerlo.
Una de las cosas que pensé, fue por qué entrar primero en modo "cartucho de 16KB" , para leer HIRAM.. Por qué no entrar directamente en modo "Ultimax"..Si se entra en modo "Ultimax" , ni hace falta cambiar la direccion en el bus, la PLA ya diría si HIRAM está a 1 o a 0, y no hace luego falta cambiar a "Ultimax"..Ya estaría el cartucho en "Ultimax"
Entonces, el ciclo completo, sería:
- Detectar acceso al KERNAL ($E000-$FFFF)
- Entrar en modo Ultimax (Con lo que la direccion que hay en el bus, ya debería activar las líneas del cartucho).
- Mirar si HIRAM está a 0
- Si lo está, devolver byte
- Si no lo está, salir inmediatamente de modo Ultimax, para que la RAM tenga tiempo de devolver el byte.

No lo he probado, pero es posible que en modo ultimax, las lineas HIRAM y LORAM no se establezcan nunca en el cartucho.Mientras se está en ese modo, no hay "banking". O sea, los bits HIRAM y LORAM en $1, son ignados. Si GAME=1, EXROM=0, da lo mismo lo que haya en $1. Pero que sean ignorados no tiene por qué significar que no se copien al cartucho. Habría que probarlo.

Los pasos del proceso que describe skoe, son 3:
1) Detectar acceso a $1
2)Recuperar el valor de HIRAM
3) Redirigir la llamada al KERNAL al cartucho.

Los pasos 2 y 3 se están haciendo en el mismo ciclo de reloj. Esto es "conveniente", ya que sólo requiere que el paso 2 cambie 1 bit del bus de direcciones.
Pero el paso 2 se podría hacer, en realidad, *justo después* de detectar la escritura en $1. Creo que es posible asegurar que, la instrucción siguiente a esa escritura, no va a estar en el KERNAL.
El problema: que ya no vale con sobreescribir 1 linea del bus. Hay que sobreescribir 3 lineas, para asegurarse de que la dirección caiga en el rango $A000-$BFFF. Ahi ya entramos en rollos eléctricos, y empiezo a perderme...Tiene la placa suficiente amperaje en sus pines, como para "imponerse" a lo que está enviando la CPU?
Suponiendo que eso funcionara, ya se sabría si HIRAM está a 1 o a 0, para cuando llega un acceso al KERNAL. Entonces sólo queda entrar en modo ultimax, o no, y devolver el byte.
Al distribuir el trabajo en 3 ciclos distintos, creo que sería posible sobreescribir el KERNAL sin necesidad de tirar de FPGA.


38
Desarrollo / Re:Pi1541 y Tapuino en 1 solo dispositivo
« en: Febrero 19, 2022, 00:32:26 »
Yo de verdad que quiero ponerme con el interfaz de usuario...Pero en la lista de cosas que quería para el cartucho, estaba una cosa que cuando leí sobre ello, pensé que era imposible..Pero ahora...igual...es posible, y es el meter KERNALs alternativos como hace EF3 y la 1541ultimate.
Esta "cosita" no es *nada* trivial. El documento que lo explica es éste: http://skoe.de/kernal/kernal-cartridge.pdf

A ver si soy capaz de explicarlo en cristiano...
Cuando se mete un cartucho "simple" en el C64 (con una ROM que contiene un juego), el cartucho utiliza 2 pines del puerto de expansión, para "decirle" al C64 en qué zona de memoria debe mapear la ROM que contiene.
Estos pines son GAME y EXROM, y dependiendo de si el cartucho los pone a OV o no, se tienen 4 combinaciones:
GAME  EXROM
  1     1       No hay ninguna rom que mapear.
  1    0        Cartucho de 8KB, mapeado entre $8000..$9FFF
  0    0       Cartucho de 16 KB mapeado en 2 bloques , $8000..$9FFF y $A000..$BFFF
  0    1       Cartucho de 16 KB mapeado en 2 bloques,  $8000..$9FFF y $E000..$FFFF
  Mientras los 3 primeros modos no afectan al resto de la memoria,
  el último modo, llamado "ultimax" (modo de compatibilidad con el Commodore MAX), hace que una gran
  parte de la RAM del C64 no esté accesible ( 2K de memoria disponible...), así que es muy raro que se use...
  Pero en este modo, sí que es posible sobreescribir el KERNAL que usa el C64, ya que la ROM del cartucho se mapea a las direcciones usadas por el KERNAL ($E000-$FFFF)
 
  Por otra parte, está que el C64 tiene, eso, 64K de RAM. Incluso si por defecto, parte de esa RAM está "oculta" porque hay una ROM en el mismo espacio de direcciones.
  Si en $E000-$FFFF está el KERNAL (ROM), también hay una RAM en ese mismo espacio de direcciones. La PLA se encarga de que, por defecto, cuando se *lee*, se devuelva el contenido de la ROM, y cuando se *escribe*, se escribe en la RAM que hay "por debajo".
  Pero desde programa, es posible cambiar todo esto: es posible hacer que la ROM sea "invisible", y que sólo se vea RAM.
  Para esto, existen 3 bits en la posición $1 de "memoria": LORAM, HIRAM y CHAREN.
  Por no liarlo más, de esos 3, si HIRAM está a 1, leer la parte de la memoria donde está el KERNAL, devolverá lo que hay en la ROM.
  Si HIRAM está a 0, leer esa parte de memoria devolverá lo que hay en la RAM.
  En ambos casos, escribir en esas posiciones, siempre es en la RAM. 
 
  La unión de HIRAM, LORAM (gestionados desde código) y  GAME y EXROM (gestionadas por el cartucho), dan los diferentes modos de memoria del C64,
  o sea, qué se "ve" en cada banco de memoria.
 
  Esto también afecta  al propio cartucho.Incluso si el cartucho establece GAME=1, EXROM=0 ,
  si LORAM está a 0, lo que está mapeado en $8000-$9FFF, es la RAM del C64, no el cartucho.
  Esto el cartucho lo tiene que tener en cuenta, para no intentar escribir nada en el bus de datos, si LORAM está a cero.
  Quien debe escribir, es la RAM (y pasan cosas malas si 2 chips intentan escribir a la vez en el mismo cable).
  De la misma forma, si HIRAM está a 0, lo que está mapeado en $A000-$BFFF, es RAM, no el bloque "alto" del cartucho (o el BASIC). 
  Es por eso que LORAM e HIRAM son 2 señales que el cartucho recibe. Aunque el cartucho reciba una dirección que corresponde a su banco de memoria, si LORAM está a 0, o HIRAM está a 0, debe considerarse "desactivado" y no hacer nada.
 
  Pero hay que diferenciar los bits HIRAM/LORAM de las señales HIRAM/LORAM del puerto de expansión,
  porque podría parecer que cuando se pone uno de los bits a un valor u otro, la señal en el puerto, cambia a ese valor.
  No funciona así. HIRAM y LORAM del puerto de expansión, sólo se establecen cuando se intenta acceder a los rangos de direcciones asociadas al cartucho.
  Y, no sólo eso, sino que la lógica es "inversa": Cuando el bit HIRAM está a 1, el pin HIRAM del puerto de expansión, está a 0.
  Por ejemplo:
  - Si hay un acceso a la posición $100 , como no pertenece a ningún bloque del cartucho, los pines LORAM y HIRAM estarán a "1", independientemente de lo que haya en los bits LORAM y HIRAM.
  - Si hay un acceso a la posición $8100, y el cartucho tiene GAME y EXROM a cualquier cosa que no sea 1/1, el pin LORAM estará al nivel "contrario" que el bit LORAM.
  El hecho de que estos pines sólo se establezcan cuando se accede al cartucho, es importante más tarde..

 
  Entonces, para poder meter un KERNAL diferente en un cartucho, tenemos que:
  -Hay que utilizar el modo ultimax.
  -Si el bit HIRAM está a 1, el cartucho debe devolver el byte correspondiente de la ROM.
  -Si el bit HIRAM está a 0, el cartucho no debe hacer nada.
 
  Vale, supongamos por ahora que lo del modo ultimax no es problema.
  Hay que saber si el bit HIRAM está a 1 o a 0, para saber si el KERNAL es visible, o no.
  Cómo es posible saberlo?
  Lo podríamos saber cuando la CPU pidiera una dirección al cartucho..
  Pero lo que se quiere es cambiar el KERNAL, que está en un rango de memoria distinto (a menos que el C64 estuviera en modo "ultimax", pero no queremos estar en ese estado)
  por lo que los accesos al rango $E000-$FFFF, no establecen el pin HIRAM del puerto de expansión..
  Otra opción sería "espiar" el puerto de direcciones y de datos. El cartucho siempre puede estar "leyendo" del bus, "espiando" todo lo que pasa por él. Si detecta que se está escribiendo
  en la posición $1, podría leer el dato que se está escribiendo, y ver qué está activado...
  El problema con esto es que esa posición $1...No está en la RAM. La posición $1 de memoria, está dentro del propio procesador. La dirección de memoria ($1), sí que es visible en el bus de direcciones.
  Pero el valor que se escribe en esa posición $1, no.
 
  Entonces, es posible saber que ha cambiado el mapa de memoria.
  Pero mientras la CPU no quiera leer del cartucho, no se puede saber a qué ha cambiado.
  (Ojo, que, además , el cartucho tiene que aparentar "no existir".Tiene sólo que reemplazar el KERNAL, cuando se llama al KERNAL. EL resto del tiempo, debe actuar como si no existiera, o sea, GAME=1, EXROM=1..Por lo que la CPU no va a leer nunca del cartucho, ni cambiar los pines LORAM/HIRAM ...)
 
  Solución: *forzar* a que se lea del cartucho.
  La forma de conseguirlo, es:
  - El cartucho no establece, inicialmente, ni GAME, ni EXROM. Como si no estuviera.Simplemente, está mirando el bus de direcciones para detectar cualquier acceso a $1.
  - Cuando detecta que se ha accedido a $1, sigue espiando al bus, esperando esta vez a que se intente acceder al KERNAL , o sea, una dirección en el rango $E000-$F000
  - Todo lo siguiente, debe ocurrir en el mismo ciclo de reloj (en realidad, medio ciclo):
     - Detectar que se va a acceder al KERNAL.
    - Si es así, se disponen de muy poquitos nanosegundos para:
      - Poner GAME y EXROM a 0 (Y, de pronto, aparecer como un cartucho de 16KB conectado al C64)
       - FORZAR un 0 en la línea 14 del bus de direcciones. Esto hace que la dirección pase de estar en el rango $E000-$FFFF, al rango $A000-$BFFF (rango del bloque alto del cartucho).
      - Esperar unos cuantos nanosegundos, a que la PLA se entere de la "pirula" que acaba de ocurrir
      - La PLA se entera de que hay un cartucho (de pronto GAME y EXROM a 0), y de que se esta accediendo a un rango del cartucho, asi que, por fin, establece el pin HIRAM, y el cartucho se entera de si KERNAL está activo, o si lo que hay es RAM.
      - Si es RAM, (pin HIRAM a 1) pues no tiene nada que hacer: libera GAME y EXROM, y, si todo ha ocurrido lo suficientemente rápido, la RAM tiene aún tiempo de devolver el byte correspondiente.
        Si el pin HIRAM estaba a cero, es que el KERNAL estaba activo. El siguiente paso, es pasar a modo ULTIMAX: se pone EXROM a 1, dejando GAME a 0, (con lo que vuelve a cambiar el mapa de memoria), y la PLA mapea el bloque $E000-$FFFF al cartucho, desactivando el KERNAL interno del C64,
        por lo que el cartucho ya puede poner el byte que sea en el bus de datos.
      - Se deja el dato activo los nanosegundos que dice el datasheet, e inmediatamente, se pasa de nuevo a modo "invisible": GAME y EXROM a 1.
   
   O sea, que en medio ciclo de reloj del C64, hay que:
   - Sobreescribir una línea del bus de direcciones. Esto ya es bastante "interesante". La CPU está intentando poner un "1" en esa línea, y el cartucho tiene que forzar a que sea un cero. Sí, esto es provocar un cortocircuito, durante unos cuantos nanosegundos.
   - Cambiar 2 veces el mapa de memoria del C64, pasando de modo "no cartucho", a modo "cartucho 16KB", a modo "Ultimax".
   
Realmente, a mí me parece todo esto .. increíble como mínimo.

Post suuuper largo, pero una de las cosas para las que estoy metido en este proyecto, es para aprender sobre el C64, y ponérselo más fácil a cualquiera que también quiera aprender sobre estas historias. Hace 3 meses no sabía cómo funcionaba un cartucho de un C64, y es todo un mundo...
(Y no he puesto nada sobre REUS, freezers y otras bestias...)

39
Desarrollo / Re:Pi1541 y Tapuino en 1 solo dispositivo
« en: Febrero 18, 2022, 03:01:31 »
Nueva actualización...La emulacion de REU (512K) ya funciona, al menos para pasar algunos test, y ejecutar Sonic:https://www.youtube.com/watch?v=xYjAM-s9Xf8

También está subido el código a github https://github.com/dashiad/MuskCartridge, por ahora sólo el código actual del cartucho.
Aún no hay un interfaz de usuario para poder cambiar cartucho, etc,etc, y es lo próximo a incluir, ya que es la (casi) última parte complicada del proyecto, el que se coordinen varias placas entre sí.
Tiene que haber un protocolo que permita que uno de los dispositivos (el "master"), se comunique con el interfaz de usuario (teléfono/ordenador), y reenvíe los comandos al dispositivo que sea.
La idea es que el código esté montado de forma que se puedan crear placas sencillas (sólo 1 dispositivo) o que combinen varios de ellos. Y que, a medida que salgan placas más rápidas, o con más RAM, sea posible intercambiar uno de los componentes por otro.

Se ha creado un servidor de discord  https://discord.gg/Eue2SJkF para agregar información sobre distintos proyectos para el c64 y otras plataformas, (incluido éste, listado como MuskCartridge) por si a alguien le interesa.

40
Eventos / Re:Regresa RetroMadrid :-) (14/05/2022)
« en: Enero 27, 2022, 21:55:45 »
Quien va de commodore? Yo me apunto!

41
General / Re:REU
« en: Enero 26, 2022, 00:08:39 »
Para mi la diskettera sigue siendo "universo expandido"  ;D

42
General / Re:REU
« en: Enero 25, 2022, 19:32:32 »
pero por otro no me vale la comparación con la disquettera que he leído en algún lado, porque ésta no modifica la capacidad de cómputo o de memoria de un C64 de serie
La REU no modifica la capacidad de cómputo o memoria. Es un dispositivo de E/S igual que una diskettera. Puedes copiar cosas hacia o desde la memoria del C64. Otra cosa es que lo haga a mucha más velocidad que una diskettera..tampoco la velocidad del disco es la misma que la de la cinta.
Que fuera un dispositivo más o menos "raro", o "caro"...Ambos términos son relativos (raro para quién, caro para quien?). Para mí, una diskettera era extraordinariamente rara y cara. Lo que no es nada relativo, sino objetivo, es que ese cacharro estuvo a la venta 4 años, desde el 86 al 90. Y que en ebay hay unas cuantas de la época a la venta, vamos, que no es un c65, o un prototipo o algo así..
Como yo no ví ni una diskettera en los 80, podría pensar que los juegos "de verdad" son los de cinta, y que el acceso "canon" , es secuencial...(y ya, para terminar la fiesta, ponerme talibán al respecto)

43
General / Re:Padswitcher64
« en: Enero 23, 2022, 02:01:09 »
No,no,ninguno,yo juego con PC.Solo digo que tendrían que imventar un adaptador para enchufar mandos USB en el commodore 64 y no estos mandos de consola tan antiguos.
Yo juego con este mando en el PC con CCS64 y va de maravilla jugar con el stick.
Está genial ese invento y lo de la barra espaciadora en el botón configurada es una pasada pero tienen que empezar a pensar en entradas USB para conectar los joypad de PC que hay modelos a patadas y super bien de precio.UN mando de estos dura la tira.Yo lo tengo desde hace 10 años y va perfecto,es eterno.
El Unijoysticle soporta mandos bluetooth. Con eso puedes conectar mandos de PC (o de Xbox, o de..)

44
General / Re:Crowdfunding, Verkami y otros micromecenazgos
« en: Enero 03, 2022, 18:06:46 »
¿Este cartucho supongo que puede servir para que las auto publicaciones de juegos en cartucho sean mas accesibles?
En principio, ese cartucho igual no lee ni .crts ... No menciona que sea capaz de hacerlo.
Es una FPGA metida en una placa tipo cartucho para el C64, con los pines conectados al puerto de expansión.
"Hagase su propia Ultimate II / TurboChameleon", sería el proyecto que podría estar mencionando en la página. Qué sentido tiene ponerle un coprocesador RISC V al 6510 es algo que se me escapa (a menos que se quiera hacer algún proyecto friki del tipo "minando bitcoins en un c64", cuando en realidad lo está haciendo una FPGA que, porque queda gracioso, está conectada a un c64)..
Vamos, yo creo que lo que se quiere a estas alturas es que lo que se conecte al puerto de cartucho, sea para apoyar los casos de uso que existen..
Abrir un "mundo de posibilidades" con el c64...Esto no es el amiga! :D

45
Desarrollo / Re:Pi1541 y Tapuino en 1 solo dispositivo
« en: Diciembre 31, 2021, 14:57:05 »
Un update rápido del estado de este experimento..
Por ahora, ya estaba:
- Soporte de cinta (con ESP32 y arduino, fácil de portar a otras plataformas).
- Soporte de disco (port casi directo de pi1541, funcionando en Teensy 4.1, Raspberry Pi Zero 2 W)
Faltaba el soporte de cartucho, sobre stm32h743, y por ahora, los cartuchos más simples (ROMs de 8 y 16Kb) ya están funcionando. También he hecho pruebas de DMA a lo "REU", y lo que he probado (escritura de cartucho a C64), parece que funciona bien.
Lo que más me interesa, que es un poco contar lo que voy aprendiendo, para que quede en algún sitio la info de cómo funciona el cartucho del C64, lo meteré en otro post.
Queda ahora dar soporte a los cartuchos más sofisticados, incluyendo los multi-banco y posiblemente los cartuchos tipo EF3. Para eso, es necesario ver cómo cargar ficheros mucho más grandes de 8/16kb.
Primero, cómo lo hace KFF. KFF tiene un stm32F405, que sólo tiene 192KB de RAM, y 1 Mb de Flash.
Eso hace que, internamente, para cargar cartuchos con más de 4 bancos (32Kb), utilice la flash interna del stm32 como si fuera una "ram". La memoria Flash no está pensada para escribir mucho en ella, tiene un ciclo de vida de escrituras, y es bastante más lenta que la RAM, pero no hay otra forma de hacerlo con ese microprocesador.
El stm32h743, tiene 1Mb de RAM, pero en estos micros hay que tener cuidado con esa cifra. Ese 1Mb de RAM está repartida entre varias RAMs distintas, de forma que, la máxima cantidad de RAM contigua, es de 512Kb, lo cual es bastante decente, pero aún no he investigado qué cosas son almacenadas ahí, si se pueden mover a otras RAMs, para dejar esos 512KB 100% libres como buffer para cargar cartuchos.
Pero, la placa que tengo, incluye una flash externa, de 8MB, conectada por QUAD-SPI..y, en muchas placas que incluyen este tipo de flash, es posible sustituirla por PSRAM. Es lo que he hecho, pero en el stm32h7xx, hay unas cuantas limitaciones de esa RAM, y aún hay que ver si el acceso es lo suficientemente rápido para acceder byte a byte a esa PSRAM, a la velocidad que requiere el C64.
Una vez terminado el cartucho, con soporte para los cartuchos típicos (ocean, freezers, etc), el problema será cómo interconectar la Raspi Zero y el stm32.
En prinicipio, la idea es crear algún tipo de protocolo donde la Raspi actúa como "master", al que se le pueden conectar "slaves". El stm32 sería un "slave", que puede recibir comandos (reset, mount) y ficheros del master (en vez de recibirlos a través de un interfaz de usuario propio).
Así, cualquier cacharrito que implemente ese protocolo,actual o futuro, puede funcionar con el master, o independientemente.
Entonces, teniendo un UI en el móvil (o en el PC, o...) se envían comandos a la Pi, (por ejemplo , "carga este fichero .crt). La PI comprueba que tiene conectado algún slave capaz de gestionar ficheros .crt, recibe el fichero .crt, y lo reenvía al slave que lo gestione. Ese slave podría funcionar también independientemente, con su propio UI , claro.
También me llama la atención cómo el reemplazo de CPU que tiene el Amiga, hecho con la PI, parece no requerir usar bare-metal...Sería muucho más fácil todo si se programa la PI sobre una distro linux.

Y, para todo el desarrollo con cartuchos, pedí placas por PCBWay...y me mandaron 10 (es ésta: https://www.pcbway.com/project/shareproject/Commodore_C64_Expansion_Port.html ). Si alguien está en Madrid y quiere una para cacharrear, me sobran unas cuantas..

Páginas: 1 2 [3] 4 5 ... 11