Autor Tema: Musk64: Pi1541 y Tapuino en 1 solo dispositivo  (Leído 5518 veces)

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13628
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #15 en: Noviembre 12, 2021, 12:23:26 »
Por lo que entiendo, emular cartucho con el STM32H750VB sería simple pero no la disketera, o iría muy justa.
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #16 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..

PacoBlog64

  • Commodore Master
  • *****
  • Mensajes: 361
  • INC $D020
    • Ver Perfil
    • PacoBlog64
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #17 en: Diciembre 31, 2021, 18:10:25 »
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)
...

Me parece muy interesante lo que estás haciendo con este proyecto, ojalá puedas terminarlo. Precisamente ahora hay mucha gente deseando tener una Ultimate 1541 II+ por la "fiebre Sonic" y un cacharrín así sería recibido como agua de mayo, ya que por la crisis de suministros Gideon no puede montar placas ni podrá en mucho tiempo, creo.
Commodoriano desde mis tiernos 7 añitos. ¿Quién necesita más de 1MHz, 64KB de RAM, 16 colores y 3 canales de sonido?

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13628
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #18 en: Enero 20, 2022, 23:15:52 »
Si, super interesante, pero menuda movida :P
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #19 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.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13628
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #20 en: Febrero 18, 2022, 16:57:06 »
Que grande Dashiad
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #21 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...)

PacoBlog64

  • Commodore Master
  • *****
  • Mensajes: 361
  • INC $D020
    • Ver Perfil
    • PacoBlog64
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #22 en: Febrero 19, 2022, 12:53: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...

Muchas gracias por la explicación y por el esfuerzo, al final saldrá algo muy potente de esto, ya verás, y si no, lo que habrás aprendido ;)
Commodoriano desde mis tiernos 7 añitos. ¿Quién necesita más de 1MHz, 64KB de RAM, 16 colores y 3 canales de sonido?

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13628
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #23 en: Febrero 19, 2022, 13:44:16 »
Yo alucino solo con la explicación, ya meterse en todo esto es para gente muy PRO...

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.
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

javierglez

  • Commodore Master
  • *****
  • Mensajes: 452
  • terminator not seen
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #24 en: Febrero 19, 2022, 22:24:12 »
Esta muy bien la explicación, creo que la entiendo bien, aunque no tengo idea del tema cartuchos
Yo como pasé del VIC20 al C128 y después directamente la 1571 nunca usé ningún cartucho. En parte porque los prg se pueden cargar en modo C128 (manteniendo la 1571 en modo burst), y esos eran la mayoría de los crackeados.
Y en parte porque lógicamente Commodore no se esforzaba en probar la compatibilidad de los productos de los third parties, y las revistas pues tampoco corrían ese riesgo. Me imagino que tardaría en correrse la voz de los cartuchos que no pueden dañar el equipo.
Así que no se me había ocurrido que los cartuchos normales, fastloaders etc no funcionasen como el easyflash y la ultimate 1541 (casualmente son los únicos 2 cartuchos que tengo)
Deseando que lleves algo a Retromadrid para ver algo en acción.
 

Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #25 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.


Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #26 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).
« última modificación: Febrero 20, 2022, 17:50:55 por Dashiad »

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13628
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #27 en: Febrero 21, 2022, 21:08:57 »
Definiendo el nombre de este proyecto. palabras de Dashiad:

Citar
El nombre del proyecto completo es Musk64 (de musketeer, "uno para todos y todos para uno", una chorrada como otra cualquiera).En github el proyecto se llama MuskCartridge, porque por ahora solo contiene el codigo del cartucho.

Lo agrego al título del hilo!
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

Gabi64

  • Commodorista
  • ***
  • Mensajes: 68
  • SYS 0
    • Ver Perfil
Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #28 en: Febrero 22, 2022, 07:27:13 »
Estamos asistiendo a una máster class.
Muchas gracias Dashiad!

Dashiad

  • Commodoremaníaco
  • ****
  • Mensajes: 160
  • SYS 0
    • Ver Perfil
Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« Respuesta #29 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.