Commodore manía
Commodore 64 => Desarrollo => Mensaje iniciado por: Dashiad en Octubre 17, 2021, 17:04:27
-
Después de muuuucha pelea, finalmente he conseguido portar Tapuino y Pi1541 para que funcionen en una misma plataforma (Teensy 4.1:https://www.pjrc.com/store/teensy41.html (https://www.pjrc.com/store/teensy41.html))
Elegí la Teensy porque da mucho rendimiento (800 Mhz) a un precio ajustado ($26 + envio), en un tamaño inferior a un arduino o una raspi, con un interfaz de programación tipo Arduino, y suficientes pines/dispositivos (SPI,I2C,etc,etc)
Portar tapuino (al menos, la versión antigua) es bastante trivial, el problema ha sido portar pi1541.. En ambos casos, había que eliminar todo el código de interfaz de usuario, y el código dependiente de plataforma...y luego adaptarlo a lo que la Teensy 4.1 puede hacer.
Éste ha sido el principal problema, ya que emular la 1541 significa que hay que emular lo que las VIAs leen del cabezal de la diskettera, y este proceso funciona a 16Mz, y, con el código original, la Teensy no cumplía el timing requerido...Por algún motivo, la pi1541 utiliza floats para mantener unos contadores que realmente podrían utilizar enteros, y con este cambio se ganan los ciclos necesarios para hacerlo funcionar.
El siguiente paso a probar, es usar un ESP32 para dar conexion wifi a la Teensy. El test inicial es descargar un d64 de la red, guardarlo en la sd, y montarlo en la diskettera. Esto abriria la puerta a tener un feed de novedades de juegos, demos, etc, descargarlos y ejecutarlos directamente desde el c64.
Además, el ESP32 también da bluetooth, como ya usa rik en su unijoysticle, por lo que también se podría integrar el soporte de mandos bluetooth dentro de la misma plataforma.
Otra de las cosas que es posible hacer con la pareja ESP32-teensy, son actualizaciones automáticas, ya que sería posible flashear la Teensy desde el ESP32 (aunque no sé si sería necesario almacenamiento adicional para hacer esto).
Por otro lado, dar soporte básico a crts no debería ser complicado...habría que ver si sería posible portar código de Kung fu flash / EasyFlash y meterlo también en la misma plataforma..
En definitiva, la idea es tener 1 solo dispositivo, que haga cuantas más cosas mejor, y, suponiendo que seguirán saliendo placas cada vez más potentes, que migrar de una placa a otra no signifique reescribir proyectos completos, pero, sobre todo, añadir formas fáciles de acceder a las nuevas producciones y ejecutarlas en el hardware real sin tener que mover tarjetas SD de un lado a otro.
Ya iré dejando por aquí los avances que haya..
-
Súper interesante Dashiad, seguiremos los avances con interés!
No sé que tan complicado sea luego poner en marcha esto por cuenta de la gente, pero toda nueva alternativa es genial!
-
Yo creo que si sustituye a Tapuino y a pi1541 ya está bien, porque ocuparía los mismos ports que un sd2iec pero con total compatibilidad.
Integrar el crt, creo que complicaría mucho el diseño, y el cartucho de easyflash es compacto y está bien estéticamente. Además esa combinación ya existe, es la Ultimate1541.
Y tampoco veo estético tener un aparato con cables a todos los conectores. Especialmente para el joystick. Si fueran dongles sería otra cosa. Si tiene que haber otro cable preferiría que fuese para el port de usuario (el modem) que queda por detrás iguamente.
De hecho a mí lo que me gustaría sería un aparato que sustituyese al modem y a la unidad de disco. El datassette me da igual.
-
Que crack!!
Con kungfu flash aún mejor!
Yo abogo por hacer "el anillo único" y reunirlos a todos (los dispositivos)!!!
-
Me parece una excelente noticia, espero que logres unificar las 3 cargas (cinta, disco y cartucho) en un solo dispositivo de bajo coste, yo ya me empiezo a cansar de andar trasteando con Tapuino, Pi1541, EF3 y KFF para cargar juegos ;D Aunque funcionan muy bien, eso es cierto.
-
Otro proyecto de multi-device: https://github.com/idolpx/meatloaf (https://github.com/idolpx/meatloaf)
Al basarse en ESP32, creo que no va a poder ir mucho más allá (emula modem + IEC básico, no tengo claro si llega a una SD2IEC).
Permite tener un servidor web en algún lado, y cargar programas a través de LOAD "HTTP://....."..
Sobre el resto de los asuntos:
- Aún estoy muy muy lejos del punto donde la estética es el problema a resolver. En cualquier caso, no tendría por qué tener cables aparte de la alimentación (posiblemente, joysticks, si se añadiera soporte).
- La Ultimate ya está para muchas cosas. Existe SD2IEC, Pi1541 y otros proyectos, por motivos de precio y disponibilidad.
- Por otro lado, cuando salió la Ultimate, simplemente, no había otra forma de hacer lo que hace la Ultimate.Una FPGA era la única cosa, en ese factor de forma, capaz de dar esa funcionalidad. Pero a medida que salen microprocesadores más potentes, esto supongo que irá cambiando (sólo hay que ver todo el uso que se le da a la raspberry pi en el mundo Amiga). Un teléfono de 100 euros tiene un procesador que va más que sobrado para hacer lo que antes requería una FPGA. A medida que esos procesadores llegan a placas "de usuario", a precios muy muy bajos, lo lógico es que las vayan sustituyendo, al menos en el mundo de la emulación de ordenadores de 8 bits.
Hay dos ventajas adicionales: primero, que no es necesario conocer VHDL o Verilog para crear dispositivos.Esa ventaja es lo que ha permitido el éxito de Arduino.No hace falta ser un ingeniero electrónico para hacer cosas.
La segunda, es la gigantesca cantidad de código open source que existe, y que es mucho más fácil de portar. Lo *ideal* sería portar directamente el código de VICE a un dispositivo pensado para funcionar con un C64 real. Si no me equivoco, la Ultimate no es open source, y, aunque lo fuera, de nuevo, ese código es territorio que requiere una cierta especialización.
Ese punto de "especializacion" es importante: la raspi no estaba pensada para cosas como replicar la disketera del C64, o un coprocesador de un Amiga. Tenía un procesador capaz de hacerlo, claro, pero eso requiere que se le programe en "bare metal", sin ningún tipo de operativo...Y para que eso funcione, tiene que haber librerías y documentación sobre cómo utilizar todos esos dispositivos (usbs, hdmi, wifi, memorias, SD...)..Documentar y crear APIs lo hacen muy bien placas como ESP32, Teensy, Arduino, etc , porque están pensadas para eso (usarse en "bare metal"), y la pi, no.
Como prueba, el código portado a Teensy 4.1 de la pi1541 tiene la mitad de ficheros. Y es porque sirven para cosas de bajo nivel de la Pi, cosa que los frameworks tipo "arduino" ya incluyen, no necesitas añadirlos a tu proyecto, saber para qué sirven, etc,etc.
Pero estaba claro que, con la potencia que da una pi, merecía la pena meterse en toda esa complejidad, en ese momento.
En resumen, procesar las señales que genera un ordenador de 8 bits (al menos), ya no es territorio exclusivo de las FPGA..Los procesadores necesarios ya están ahí, muchas veces falta simplemente una API simple.
-
No se, yo te hablo como usuario, de Arduino estoy pez.
Mi comentario iba en la línea de que creo que la mayoría de la gente estaría encantada con un trasto que reúna tapuino+1541 y además no requiera una RPi. Y para fastloader/cartuchos ya estaría Easyflash que se complementa perfectamente. Y por tanto no necesitarías añadir mucha cosa más. Pero es solo una opinion claro.
Yo no tengo PI1541 pero en términos de compatibilidad todo el mundo habla bien, o al menos nadie habla mal, o sea que me imagino que va bien.
La Ultimate 1541 con el tema este del sector de semiconductores parece ser que no cree que pueda reanudar la producción y está estudiando rediseños.
-
Emulación de cartucho (y muchas otras cosas) con Raspberry Pi:
https://github.com/frntc/Sidekick64 (https://github.com/frntc/Sidekick64)
- C64 kernal replacement,
-GeoRAM/NeoRAM-compatible memory expansion,
-freezer cartridges
-Function ROMs on a C128, or
-multiple SIDs and Sound Expander/FM emulation (up to 8 SIDs, e.g. to play The Tuneful 8)
-simplified Datel and Sequential MIDI interface with built-in SoundFont-synthesizer (slightly modified
version of TinySoundFont)
-TED-sound and Digiblaster emulation for C16/+4 (to have all sound devices on one output)
But many more things are imaginable, e.g. 80 column cards with HDMI video output, custom accelerators/coprocessors etc.
Hablando con el autor, voy a portar el código de la pi1541 para que funcione con Circle, el framework de desarrollo para Pi en baremetal que usa Sidekick, y así poder integrarlo en su proyecto.
-
Y da la Rpi para todo lo otro más esto?
-
He estado estos días dándole vueltas a cómo integrar el puerto de cartucho.
Hay 2 problemas a resolver, en principio:
- El número de pines. Ni la raspi , ni ESP32 tienen suficientes pines como para conectar directamente al puerto.La Teensy si tiene, pero prácticamente no quedaría para otra cosa. Las alternativas serían usar shift registers o multiplexadores de I/O. Hay que tener en cuenta que los accesos al bus de datos/direcciones, hay que resolverlos en medio ciclo de reloj, o sea, a 2 Mhz, lo que deja 500 nanosegundos para proceso.. Esto descarta los shift registers. Los multiplexadores de I/O, o añaden muchos componentes, (multiplexores 2 a 1) o son lentos (multiplexores 4 a 2, 8 a 3..)
- Interfaz a 5V. Raspi, ESP32 y Teensy, no soportan 5V en sus pines. Así que hay que usar conversores de nivel. Y para el número de pines que tiene el puerto de cartucho, eso son *muchos* conversores de nivel. Se podría hacer con voltage dividers, pero al parecer a altas frecuencias añaden problemas.
En teoría, sería posible usar multiplexores 2 a 1, que a la vez soportaran 5V..Pero, de nuevo, son muchos componentes.
Hay algo que resuelve ambas cosas, y es usar un stm32, que es lo que lleva la kung fu flash (reemplazando el uso de fpga que hace EasyFlash 3), que tiene pines para aburrir (placas basadas en el STM32H743VIT6 , tienen más de 80 pines, y cuesta 16 euros). Esto tiene la ventaja de que simplemente, habría que portar el código de la kung fu flash. Y la desventaja de que esos procesadores funcionan a un máximo de 480Mhz, y, al menos con la teensy, esa velocidad no sería suficiente para emular la diskettera.
Eso lleva a un tercer problema: no bastaría con emular cada cosa "por separado", sino "a la vez".La diskettera y el datasette podrían ser excluyentes (o funciona una cosa, o funciona otra), pero no, por ejemplo, la diskettera y el cartucho. Y en esto, sí que las FPGA aún ofrecen ventajas sobre los microprocesadores. Ninguno de los anteriores es capaz de emularlo todo a la vez. Ahora mismo, la Teensy 4.1 me deja entre 240 y 180ns libres por ciclo. Siendo muy optimista con las optimizaciones que podría hacer, llegaría a 350-290ns libres por ciclo, que dudo que diera para mucho (teniendo en cuenta que tendría que multiplexar pins, etc,etc).
En definitiva, es necesario tener una combinación de micros/placas para hacerlo todo.Por lo que veo, la mejor combinación sería una raspberry pi zero w, sobre todo la versión 2 que ha salido hace unos días, ya que tiene 4 cores (el mismo procesador que la raspi 3), y el stm32.
Así que, por ahora, esperar a que me llegue el stm32, ver si puedo meter el código de kung-fu flash tal cual, y luego adaptarlo.
-
He estado estos días dándole vueltas a cómo integrar el puerto de cartucho.
Hay 2 problemas a resolver, en principio:
- El número de pines. Ni la raspi , ni ESP32 tienen suficientes pines como para conectar directamente al puerto.La Teensy si tiene, pero prácticamente no quedaría para otra cosa. Las alternativas serían usar ...
Muy interesante todo esto, parece un problema realmente complicado.
-
Yo creo que te conviene crear una buena versión optimizada para cinta y disco. Luego mas adelante cuando haya nuevo hardware que permita agregar lo del cartucho entonces ver si se puede portar o agregar, pero creo que ahora te vas a meter en un berengenal tremendo y el resultado parece mas cosa de Frankenstein!
En fin, hagas lo que hagas desde aquí te seguimos!
-
Pequeño update, ahora que ya tengo la Pi zero 2 w, y la STM32H750VB ..
Por un lado, tengo más o menos claro que el interfaz de usuario es mejor que esté en el móvil, que añadirle una pantalla al conjunto.Esto abre muchas posibilidades interesantes.
La conexión podría hacerse por bluetooth, con la Pi zero. El problema es que en bare metal, no hay mucho desarrollado para soporte de bluetooth, por cuestiones legales.Otra posibilidad es hacerlo vía wifi, un pelín más engorroso a la hora de configurar, (hay que especificar ssid, password, ip estática), pero mucho más flexible en la comunicación en sí.
Me ha dejado bastante sorprendido el STM32H750VB ... La placa en la que viene (16 euros), tiene 88 pines!! (más grande que la pi zero, más pequeña que la pi 3). La kung fu-flash se basa en el STM32F405GTR, que funciona a 168Mhz, con 1.25 DMIPS/MHz...Mientras la familia H750VB funciona a 480Mhz, con 2.14 DMIPS/Mhz ..
O sea, que no es que el 750 sea casi 3 veces más rápido que un micro que ya es capaz de emular el cartucho.. sino que ejecuta más operaciones por Mhz.
De hecho, el 750 tiene un coremark de 2424 Mhz, ligeramente superior incluso que el de la Teensy 4.1 (2313)..
Como referencia, un Arduino Uno tiene un coremark de 7 (!), un ESP32 (usado, por ejemplo, en el modem para el C64), 351 ... El BCM2837 (raspberry pi 3, raspberry pi zero 2 w), 15363 (4 cores, a 1.2 Mhz)
Asi que parece que el stm32h750 más que se sobra para el cartucho, y yo diría que sería capaz de emular la diskettera (pero no creo que las 2 cosas a la vez, ni dar wifi...)
Por otro lado, la pi zero 2 w, tiene el mismo procesador que la raspi 3 (con la mitad de tamaño y precio), pero con una velocidad de reloj ligeramente inferior. Asi que quise probar si la pi1541 funciona con esta nueva placa.
Hice el test, y, sí, funcionar...funciona. O sea, arranca...Pero no le da para comunicarse bien con el C64.
La pi1541 tiene soporte para la pi zero original, que lleva un procesador distinto, y para la que se hicieron optimizaciones que, si se activan tambien para el procesador de la pi3/pi zero 2, hacen que sí que funcione pi1541 decentemente. Estas optimizaciones son las mismas que hice para portarlo a la teensy 4.1, básicamente, evitar aritmética no entera (floats, doubles)
-
Me pierdo con tantos datos de procesadores y demás, tendrías que hacer un resumen para ignorantes :D
-
Así, resumido, sería algo del tipo:
Quiero incluir soporte de cartucho, lo que requiere muchos pines.
Un cacharro con tantos pines como necesita el cartucho, no es fácil de encontrar (en formato "plaquita"ya hecha, y barata...Si quieres diseñar tú la placa, soldarlo, etc...si..pero por ahora eso sí que es un lío para mí..).
El que encontré, es de la misma familia que el que usa kung fu flash...Y parece que es como 5 veces más rápido (en total), sólo costando unos 16 euros. Asi que el código debería ser fácil de portar, y va sobrado de velocidad.
Los numeritos los pongo como referencia, porque con tanta placa, parece que son todas iguales...
- un arduino uno tiene "7" de velocidad.
- un STM32H750VB tiene "2424" (346 veces más rápido)
Por lo que he visto, emular la 1541 con el código de la pi1541, requiere una velocidad de unos "2500".
Y emular el cartucho, parece que requiere una velocidad de "470", más o menos.
-
Por lo que entiendo, emular cartucho con el STM32H750VB sería simple pero no la disketera, o iría muy justa.
-
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 (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..
-
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.
-
Si, super interesante, pero menuda movida :P
-
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 (https://www.youtube.com/watch?v=xYjAM-s9Xf8)
También está subido el código a github https://github.com/dashiad/MuskCartridge (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 (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.
-
Que grande Dashiad
-
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 (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...)
-
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 (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 ;)
-
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.
-
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.
-
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.
-
Me autorespondo... Según otro documento de skoe, absolutamente alucinante:
http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf (http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf), la ecuación de la PLA para el pin ROMH es:
-- # 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).
-
Definiendo el nombre de este proyecto. palabras de Dashiad:
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!
-
Estamos asistiendo a una máster class.
Muchas gracias Dashiad!
-
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.
-
Por fin! Primer upload del teléfono al cartucho, por bluetooth!
https://www.youtube.com/shorts/and0fWYy-5Y (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...
-
Dando un paso más...He integrado la gamebase64 en la aplicación del móvil. Por ahora sólo funciona la búsqueda, ya que la mayoría de los juegos están en t64/d64 , y aún no me he puesto a integrar la emulación de disco y cinta con la de cartucho.
Las emulaciones por separado están hechas. Lo que les queda, es implementar el protocolo que le permite enviar y recibir órdenes / datos por bluetooth.
Este protocolo es común, es el mismo código para todos los dispositivos (todas las emulaciones son en C / C++), así que no debería ser demasiado complicado.
Al final, creo que la mejor arquitectura es usar un ESP32 emulando cinta y modem en 1 core, y siendo "master" (comunicación con el teléfono) en el otro core. Éste sería el único dispositivo requerido. El cartucho, disquetera, etc,etc, serían todos opcionales. Si existen, deben notificar al master, el cual notifica al teléfono, el cual habilitaría el abrir los tipos de fichero correspondientes.
-
La que estas liando... :P
Gracias por la actualización.
-
Un cambio de trabajo y varios proyectillos que se han ido metiendo por medio han retrasado el seguir trabajando en este proyecto... Pero finalmente, ya está finalizada la emulación del datasette (sólo reproducción).
Con esto, las emulaciones que me propuse inicialmente (disco, cartucho y cinta) estarían terminadas (la emulacion de disco es un port de Pi-1541, mientras el código de cartucho y cinta están hechos de cero).
Así que las piezas sueltas están terminadas, y queda añadir el "pegamento". Mientras el test de cartucho que hice hace tiempo comunicaba el teléfono directamente con el cartucho, ahora hay que comunicar los dispositivos entre sí, mientras uno de ellos mantiene la conexión con el teléfono
(el test que hice con el cartucho suponía que éste era la única cosa conectada).
Info técnica:
La principal diferencia con otras implementaciones (tapuino), es que uso una caracteristica "rara" del ESP32, llamada RMT, al que se le puede pasar una serie de pulsos, con sus duraciones, y éste dispositivo se encarga de enviar los pulsos, liberando de trabajo al procesador. Asi que usando sólo 1 de los 2 cores del ESP32, es posible tanto simular el datasette, como seguir recibiendo mensajes del teléfono por bluetooth (y aún quedaría 1 core para emular, por ejemplo, un modem).
Con todo esto, la próxima actualización ya debería ser la primera versión funcional!
-
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.
-
Las marcas para botones que hay en la PCB, en realidad, lo he añadido sin tener todavía muy claro para qué van a servir, ya que el control debería realizarse desde el teléfono. Aparte de la placa STM32, lo único que hay soldado es un set de pines (en la izquierda), para comunicarlo con el ESP32. Esto no sería necesario con la placa final, donde serían simplemente trazas en la PCB.
Me refiero con esto a que el único componente que es necesario soldar a la PCB, es la placa en sí misma.
Por cierto, que la placa ha bajado muchisimo de precio desde los tiempos del COVID...LLegó a estar a 80 euros, mientras, a día de hoy, está a 23 en aliexpress (https://es.aliexpress.com/item/1005005188963000.html?spm=a2g0o.productlist.main.1.53c6145dZR1DVD&algo_pvid=22189ef2-3fa8-4b3b-9ab2-6d6247148038&algo_exp_id=22189ef2-3fa8-4b3b-9ab2-6d6247148038-0&pdp_npi=4%40dis%21EUR%2137.78%2123.42%21%21%2139.99%21%21%40211b442116933063359284643e1b26%2112000032382067788%21sea%21ES%21143796154%21&curPageLogUid=B4dOYbIGrJ2X).