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 ... 11
1
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Agosto 29, 2023, 12:56:11 »
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.

2
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Agosto 29, 2023, 12:47:27 »
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.

3
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Agosto 18, 2023, 02:08:58 »
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!

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

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

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

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

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

5
Lo que se va a guardar es un volcado de RAM, que no es ni un .D64 ni un .CRT.
Un .CRT tiene que contener un programa , ya que el ordenador va a ceder la ejecución al cartucho (un D64 no tiene que tener un programa necesariamente).
Sí sería posible crear un CRT que lo que haga sea ejecutar un código que lo que haga sea
restaurar un estado que tenga almacenado.

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

7
Ensamblador / Re:Scroll de varias pantallas a izquierda y derecha
« en: Abril 26, 2023, 01:04:57 »
El truco imagino que estará en forzar que cuando se hace scroll en cualquier sentido, se acabe dibujando siempre una columna de pantalla entera. Esto ralentiza un poco el cambio de sentido (entre 1 y 7 frames según la posición de scroll que estemos mostrando, si no me equivoco) y añade cierta sensación de que el scroll "va por detrás" del protagonista, pero evita que se queden columnas a medio pintar.
Ya hace mucho que lo hice, asi que no recuerdo los detalles, pero cuando haces scroll, entras en el modo en el que el c64 deja visibles sólo 38 columnas, en vez de 40, por lo que las columnas "incompletas" de los lados, no las ves (si entiendo a lo que te refieres).

8
Ensamblador / Re:Scroll de varias pantallas a izquierda y derecha
« en: Abril 26, 2023, 00:56:10 »
Lo que no entiendo muy bien es lo que dices de "tengo 3 pantallas", cada una con su propio comienzo.
Cuando he implementado scroll, yo he montado un "mapa". Un mapa con scroll puede tener perfectamente 3 pantallas y media de ancho, y tiene 1 único comienzo en memoria.

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

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

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

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

 

9
Problemas Hardware y Software / Re:Problema de señal
« en: Abril 19, 2023, 16:02:36 »
Por lo que dices, podría ser que hay algo que a medida que se calienta el ordenador, empieza a fallar...Por si acaso, limpiaría los contactos de todo los chips que estén en sockets, y vería si hay algo que varía mucho de temperatura a medida que pasa el tiempo (podría también ser un condensador, un transistor..) La conexión de vídeo la tienes por la salida de antena, o por A/V ?
Lo del datasette...empezaría por ir tocando el azimut.

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

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

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

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

11
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Enero 18, 2023, 19:10:27 »
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.

12
Desarrollo / Re:Musk64: Pi1541 y Tapuino en 1 solo dispositivo
« en: Diciembre 29, 2022, 02:16:32 »
Por fin! Primer upload del teléfono al cartucho, por bluetooth!
https://www.youtube.com/shorts/and0fWYy-5Y

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




13
General / Re:Nuevo proyecto: Retroterm, RetroBBS y TURBO56K
« en: Diciembre 03, 2022, 16:55:44 »
Usar algún motor de MUD? No sé si hay alguno que permita añadir datos a las habitaciones, que sean parseables en el cliente, y sería multiusuario.
Un juego que a mi me encantaría ver en el C64, es el dominion (https://github.com/fantastic-penguin/dominion) , que hacía furor en la facultad... Tipo "civilization" multijugador en modo texto (basado en turnos)..
En general, juegos antiguos de UNIX, si se parsean las secuencias ANSI, creo que funcionarían con un modem

14
General / Re:Duda sobre cartucho ¿Commodore? ¿VIC? ¿otro?
« en: Noviembre 22, 2022, 02:50:12 »
Juer...con tornillos largos que atraviesen la carcasa y la placa...que calentar esa tuerca para que el estaño se le pegara, habrá costado lo suyo, en tiempo, y en estaño :-P

15
General / Re:Duda sobre cartucho ¿Commodore? ¿VIC? ¿otro?
« en: Noviembre 21, 2022, 17:23:08 »
Lo que me llama la atención es que debajo parece que hay soldada una tuerca??
Mirando las otras fotos parece que hay un agujero por la parte de abajo de la carcasa del cartucho... Estaba el cartucho atornillado a algún sitio para que no se moviera?

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