Arcades de los 80 en ZX-UNO (II)

Cores de los que existe documentación pero no se ha intentado aún portarlos al ZX-Uno / Cores for which documentation or source code exists, but no ports have been attempted to the ZX-Uno yet
Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 03 Sep 2016, 23:26

Ya he instalado todo al estado en que lo dejé allá por 2015. Pongo fotos del funcionamiento en que dejé el BombJack.
Como véis, falla los fondos. Ahora mismo desconozco por qué, pero parece mas un fallo de velocidad de algún reloj, que de ROM. Pero no descarto nada.
Mañana haré unas pruebas, a ver si avanzo durante la mañana. Sino lo consigo (ando muy espeso con la edad), le paso los fuentes a Quest y a ver si él da con el fallo.

Imagen

Imagen

Imagen

Avatar de Usuario
Quest
Mensajes: 900
Registrado: 27 Sep 2015, 00:20

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por Quest » 04 Sep 2016, 08:37

Perdón por no pasarme mucho estos últimos días por el hilo, estoy teniendo unos días "finos" últimamente :( y para colmo ayer se me rompió el móvil (ala!, otro gasto inesperado y cosas importantes perdidas...)

En fin, a ver si vuelvo a sacar un poco de tiempo. Además ahora estamos preparando también todo el tema de los envíos... en fin, ya sabes.

Gracias por molestarte en revisar todo jepalza. Con respecto al BombJack, ya estuve trasteando un poco con él y lo dejé de lado, con idea de retomarlo más adelante. El principal problema que nos encontramos con esta máquina es que sus roms ocupan más de 100K, y por tanto no caben todas en BRAMs de la FPGA (en las otras máquinas sí, y no teníamos este problema), ya que disponemos de unos 70K de espacio aproximadamente. Ahora no lo recuerdo bien (no estoy en mi ordenador, estoy fuera) pero basándonos en lo ya existente, se usaban parte de las roms en BRAM y el resto se volcaba a SRAM leyéndolo desde una FLASH, y ya se usaban una vez están en SRAM. Probablemente lo que te pasa de que faltan gráficos es eso, que los que faltan no los está leyendo de ningún sitio (desconozco cómo estás reutilizando ese código, pero parece ese el problema a simple vista), o lo que está leyendo de SRAM está vacío porque no se han copiado esas roms de fondos/sporites/loquesea a la misma.

Lo dicho, a ver cuando saco un rato, y le echamos un ojo juntos si quieres, aunque tengo como prioridad primero adaptar los cores actuales que me quedan pendientes de meter las combinaciones de master reset, tecla de vídeo, etc, más o menos para cuando lleguen los ZX-UNOs a las casas de los backers.

Saludos!!
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 04 Sep 2016, 11:30

Pero el problema de BRAM no debería afectar, y menos aún el de espacio para guardar ROMS. Es la misma FPGA LX9, por lo tanto, mismo tamaño de BRAM libre en ambos modelos, al menos, con un core limpio, sin nada dentro del ZXUNO.
Lo que hago, es "pegar" las ROMS (128k) seguidas del .BIT final, y el resultado lo meto en un MCS y lo grabo en flash. Si solo usara el BIT (el de tamaño 333k) , el juego, al iniciarse, no leería las ROMS reales, y se ejecuta SIN roms, y entonces sí que aparece el problema de los gráficos, al estar estos vacios o con datos aleatorios.

Lo que he hecho es pegar todas las ROMS, haciendo que las de 4k sean de 8k para que todos los bancos sean iguales en tamaño, con lo que se obtienen un total de 128k de roms, y el BIT final es de 461k.

Pero no hay manera, los gráficos salen mal.

Pienso mas en un problema de reloj. Tenemos que obtener 48mhz exactos desde los 50 del ZXUNO, y eso implica unas divisiones/multiplicaciones raras, y no llego nunca a 48. He probado lo mas bestia a dividir entre 25 (50/25=2) y multiplicar por 24 (24*2=48) pero esta operación no le gusta mucho a la Spartan.

Lo mas aproximado han sido 48 con algo, usando valores mas bajos, y se nota la diferencia, los fondos son mas claros, pero siguen con el problema de los "glitches" (no sé ni como llamarlos en cristiano).

Pero bueno, sigo probando.

Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 04 Sep 2016, 20:30

Tras hacer varias pruebas, juraría que el problema es la velocidad. Es MUY sensible a cambios. Necesita cuatro relojes, de 4, 6, 12 y 48, que en el papilio con 32, se obtienen fácil (primero 32/2, y con los 16, se multiplica por 3, y tenemos los 48 iniciales). Luego, con esos 48, y mediante contadores, se consiguen los 4,6 y 12 fácil.
Pero en el ZXUNO, lograr 48 desde 50 es complicado, y si no tenemos 48 exactos, tampocos lograremos luego los 4,6 y 12.
He probado a crear 4,6 y12 por separado, de modo exacto, y la imagen cambia por completo, se ve limpia, sin fallos, pero no sale el fondo, por que el 48 no es exacto. Juraría que el 48 es para sincronizar la copia de la flash dentro de la SRAM, y al no estar bien sincronizada, no se copia nada .

Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 08 Sep 2016, 07:06

Creo haber descubierto el fallo del BombJack. Según esta traducción a lo bestia cogida de la página de su autor:

Pero sólo tengo un chip SRAM única para almacenar todos ellos. ¿Cómo puedo fingir tener un montón de chips de ROM separados sólo por el uso de un solo chip SRAM? Después de una buena cantidad de simulación y examinar el diagrama del circuito, resulta que la respuesta es la multiplexación por división de tiempo. Mediante la ejecución de la SRAM en un reloj de 48Mhz, resulta que es posible falsificar la aparición de múltiples chips ROM almacenándolos en diferentes áreas de la SRAM y rápido de leer cada dirección de ROM y presentar los datos a la meta justo a tiempo.

Al tener que simular la SRAM como si fueran varias ROM, ha tenido que inventar un sistema que va sirviendo un poquito de cada ROM según el ciclo en el que se encuentra, aprovechando ciclos muertos. Eso hace que un solo fallo de sincronización se desplace TODO el conjunto de ROM simuladas. Es como si metiésemos un byte de mas al principio de cada ROM y se desplazase en contenido, haciendo que nada sea visible.
En el caso del BombJack, solo está correcta la ROM0 la de los caracteres, por que empieza en la dirección "0", y ahí no hay vuelta de hoja, pero según avanza, se va sumando un ciclo extra que hace que cada sucesiva ROM se desplace uno o dos bytes, con lo que el resultado es aleatorio, unas veces se muestra bien, otras fatal.

He encontrado una solución "a pinrel" que consiste en rehacer cada ciclo que accede a cada ROM (no son muchas, solo 12 o 13) y cambiar su ciclo por el mas cercano. Pero por ahora solo funciona bien con las primeras ROM, por que según avanza, pierde mas ciclos y cuesta mas ajustar.

El porqué de este desplazamiento, lo interpreto debido a la velocidad mayor del ZXUNO (50mhz) frente al Papilio (32mhz). Eso hace que el ZXUNO acabe antes que lo haría el Papilio y cuando llega la rutina de mapeos de ROM, se han perdido ciclos y se ha descompensado. Para sincronizar los ciclos, emplea la señal HBLANK de la VGA, y usa un reloj de 48mhz. Aquí es donde me pierdo, no entiendo de señales de vídeo, y no veo como poner una "pausa" para que se inicie en el momento adecuado.

Seguiré probando esta tarde si puedo, y si logro sincronizar a mano, lo dejo así.

Avatar de Usuario
jotego
Mensajes: 158
Registrado: 11 May 2016, 23:45
Ubicación: Valencia
Contactar:

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jotego » 08 Sep 2016, 09:06

(Sin haber leído el hilo desde el principio, se me ocurre que...)

Prueba a construir varias cachés para el acceso a la SRAM de forma que puedas simular la existencia de varias ROM. Seguramente puedes acceder a la SRAM más rápido de lo que el juego precisa. Así cuando vaya a acceder a un carácter lee de golpe varios bytes que luego puedes servir más despacio (el primer byte tendrás que servirlo al vuelo, para los demás usarás la caché).

Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 08 Sep 2016, 09:52

Gracias Jotego, la idea es buena, pero veo complicado cambiar el código de acceso a la SRAM que ya lleva implementado. Por supuesto, tengo en cuenta tu idea, que si fuera Basic o C++ estaría chupado, pero en VHDL se me antoja complicado. Mi nivel de VHDL o Verilog es bajo tirando a "kk", lo justo para divertirme cambiado códigos ya existentes.

Avatar de Usuario
Kyp
Mensajes: 213
Registrado: 18 May 2016, 20:16

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por Kyp » 08 Sep 2016, 16:21

Ayer, según iba leyendo el artículo original (por lo de cargar datos a la SRAM al arrancar), me iba maravillando de que hubiera hecho el core tan fiel al diseño original, pero sabiendo como funciona la máquina, seguro que alguien que sepa más de HDL que yo (tampoco me considero ni mucho menos un experto, lo poco que se es de 'jugar' a hacer un Spectrum) puede 'reconstruir' la máquina de una forma más eficiente desde el punto de vista de la FPGA y salvar así los problemas con que te encuentras. Por lo que he leído, una de las cosas más complicadas del diseño con HDL es tener varios dominios de tiempo (algo de eso pasa con la SDRAM y así me ha ido). Por otra parte, cuando compré la Papilio me preguntaba por qué iba a 32 MHz en vez de ir más rápido, que podría sin ningún problema. Ahora veo que el diseñador tenía sus razones, parece que 32 MHZ da mucho más juego con el DCM que otros valores.

Avatar de Usuario
jepalza
Mensajes: 613
Registrado: 02 Oct 2015, 18:52

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por jepalza » 08 Sep 2016, 18:10

Kyp escribió: Por otra parte, cuando compré la Papilio me preguntaba por qué iba a 32 MHz en vez de ir más rápido, que podría sin ningún problema. Ahora veo que el diseñador tenía sus razones, parece que 32 MHZ da mucho más juego con el DCM que otros valores.
Pensamos igual en eso de los 32mhz. Es un valor mas divisible que el 50, y se obtienen valores mas típicos, como 6 o 12 con una simple división.

Avatar de Usuario
Quest
Mensajes: 900
Registrado: 27 Sep 2015, 00:20

Re: Arcades de los 80 en ZX-UNO (II)

Mensaje por Quest » 08 Sep 2016, 18:17

No hay ningún problema con nuestro oscilador de 50Mhz para obtener esos valores. En la Spartan-6 disponemos de las primitivas PLL que nos permiten hacerlo hasta con 6 relojes de salida. Ajustando multiplicador y divisor principal, y luego los divisores para cada una de las salidas. (Ejemplo, divisor principal 1, multplicador 16, obtienes 800 y dividiendo por 100 en la primera salida obtienes 8, etc). Mejor usar PLL en vez de DCM en la mayoría de los casos, para mi gusto.

Echad un vistazo a la documentación de la Spartan-6 para más información.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Responder