SAM Coupé en ZX-Uno (¿alguien dijo SAM-Uno?)

[mcleod_ideafix]

EDITO: Es curioso que el turboMon al cargarlo en el SimCoupé aparece el color de fondo del título, barra inferior y barra de selección en azul marino y los títulos de los registros, pila, etc, en verde, mientras que en el ZX-UNO sale al revés verde y azul respectivamente...

A ver, que me estoy liando... En el modo 3 (512x192), ¿cómo exactamente se calcula el color que tiene un pixel?

[Quest]

Veo que ya está arreglado, así que...

[mcleod_ideafix]

Veo que ya está arreglado, así que...

Sí, pero me he quedado un poco a cuadros. De siempre he supuesto que en el modo 3, los dos bits de cada pixel son los dos bits menos significativos del color, y en el mismo orden que hay por ejemplo en el modo 4. Es decir, el bit más significativo del byte es también el bit más significativo del pixel. Pues resulta que en el modo 3 es al revés. Y lo malo es que no encuentro ni un solo documento en el que explique el layout de la pantalla para cada uno de los modos del SAM. El manual técnico "oficial" lo despacha en un párrafo, y el "no oficial" sólo menciona el modo 4. Los demás, nada.

[mcleod_ideafix]

El TEST 3 ya tiene sonido SAA1099. Al menos, una versión preliminar que he escrito hoy domingo de un tirón . Las envolventes aún no están implementadas, pero todo lo demás sí (sus 6 canales, los 2 generadores de ruido, los 6 mezcladores estéreo, etc). A un nivel superior hay otro mezclador que lleva la señal del SAA y la mezcla con la de EAR, MIC y el BEEPER, así que se sigue escuchando el sonido "de 1 bit", y esta vez también se escucha MIC.

Prince of Persia, y alguna otra cosa que he probado, suena estupendamente, incluso sin las envolventes. No sé qué juegos harán uso de ella.

Manic Miner hace una cosa extraña: el sonido de la pantalla de presentación se escucha sin problemas. Le das a ENTER para jugar y el sonido de juego también es correcto. Sin embargo, cuando terminas la partida y vuelves a la pantalla inicial, se han perdido notas. No veo nada raro en el core del SAA1099 para que pase esto. Puede ser algo relacionado con las envolventes que aún no están (pero la primera vez sí funciona) o.... estoy empezando a sospechar que no tiene nada que ver con el SAA y es en realidad algún tipo de corrupción de memoria, que igual tiene algo que ver con el extraño que hace este juego cuando pierdes una vida o cambias de pantalla, en donde en la parte inferior, por un momento, se ve lo mismo que en la parte superior.

[radastan]

Mc Leod, eres más peligroso que el Equipo A en una ferretería. Me voy una semana de vacaciones y cuando vuelvo ya casi tienes terminado lo más gordo de la implementación del SAM.

Ahora me planteo si no convertir mi ZX-Uno en un Sam-Uno, porque Spectrum tengo varios pero Sam ya no tengo ninguno.

[Quest]

Madre mía, me levanto hoy y me encuentro con esto

El SAA1099 implementado en tan poco tiempo!!! no se qué decir! Bueno si, que BRAVO! Música maestro
Un sueño hecho realidad, en escasos días, Sam Coupé en FPGA con sonido. En el TEST3 aún, y ya está así de avanzado... quién diría que se trata sólo de un test!!

Bueno, pasando ahora al testeo del nuevo core, la verdad es que me he quedado alucinado. Suena estupendamente. De lo que he probado hasta ahora (aún me quedan cosas) he notado lo siguiente:

- Imagino que además de introducir el SAA1099 se ha tocado alguna cosita más en el core. Lo digo porque en la demo SlowMotion 2, por ejemplo, se han arreglado los 2 problemas que quedaban, el del efecto del prisma retorcido, que hasta la versión anterior del core se seguía viendo mal (cuadros oscuros entre medio del prisma), ahora se ve bien!! se ve como se debe ver, en su degradado de grises. Además también se ha solucionado el problema de los campos invertidos en el modo entrelazado hi-res

- En la demo SCDIT, por un lado he notado que falta algo en el sonido, un canal/voz, o eso parece. Donde se puede apreciar bastante bien es durante un par de efectos sobre todo, en el de las curvas de colores ondeantes (justo en posterior a los bobs y anterior a la foto de C3PO), durante los de lentes un poco también y en el de truecolor. La voz principal, la del sonido más agudo, no se oye.

- En la demo SCDIT también, ahora ha empeorado el efecto de las imágenes truecolor que se había corregido en la versión anterior del core. Vuelven a temblar hacia la izquierda y una banda vertical de unos 12 o 15 píxeles de ancho aparece descolocada en el lado derecho.

No he probado nada más de momento, pero esto avanza a una velocidad increíble

Gracias por el currazo.

EDITO: Ah, se me olvidaba comentar que suena bastante bajito, tengo que poner el volumen entre 3 y 4 veces más alto que antes (comparación con beeps)

EDITO 2: Al margen de lo anterior he encontrado 2 cosillas que creo que se me habían pasado en días anteriores
- En el juego CRAFT! el título que son letras grandes en azul, la parte inferior de las letras se ve roja, cuando deberían ser azules enteras..
- En el Tetris, no recuerdo si ya lo comenté o no, pero bueno, faltaría el scroll de texto sobre banda gris en la línea inferior de la pantalla

[mcleod_ideafix]

- Imagino que además de introducir el SAA1099 se ha tocado alguna cosita más en el core. Lo digo porque en la demo SlowMotion 2, por ejemplo, se han arreglado los 2 problemas que quedaban, el del efecto del prisma retorcido, que hasta la versión anterior del core se seguía viendo mal (cuadros oscuros entre medio del prisma), ahora se ve bien!! se ve como se debe ver, en su degradado de grises. Además también se ha solucionado el problema de los campos invertidos en el modo entrelazado hi-res

Es que resulta que el efecto twister funciona en modo 3. Al leer los créditos de la demo ellos lo explican, y entonces cuando vi que salía mal, y que además los colores del TurboMON también salían mal, inmediatamente conecté las dos cosas. Es lo que te preguntaba antes de cómo funciona el modo 3. Resulta que los dos bits que forman un pixel en el modo 3 no tienen el significado esperado de BIT1 BIT0 (los dos bits menos significativos para averiguar qué entrada de la paleta hay que usar) sino que es AL REVES: BIT0 BIT1. Esto no es así en el modo 4, así que cuando implementé el modo 3 lo hice con el mismo orden de bits que en el modo 4. No sé por qué en el modo 3 es al revés. No he encontrado ningún texto en donde se explique bien cómo se organiza la pantalla en los modos 3 y 4. Al SAM le falta un montón de documentación, y el manual técnico en algunos sitios tiene puntos oscuros, y en otros, directamente te confunde (como por ejemplo sobre los valores de LPEN cuando no se está escaneando la parte de "paper" de la pantalla)

- En la demo SCDIT, por un lado he notado que falta algo en el sonido, un canal/voz, o eso parece. Donde se puede apreciar bastante bien es durante un par de efectos sobre todo, en el de las curvas de colores ondeantes (justo en posterior a los bobs y anterior a la foto de C3PO), durante los de lentes un poco también y en el de truecolor. La voz principal, la del sonido más agudo, no se oye.

Recuerda que puede que sea por el tema de las envolventes que aún no está implementado.

- En la demo SCDIT también, ahora ha empeorado el efecto de las imágenes truecolor que se había corregido en la versión anterior del core. Vuelven a temblar hacia la izquierda y una banda vertical de unos 12 o 15 píxeles de ancho aparece descolocada en el lado derecho.

Esto puede que se deba a un cambio que hice, después de que Simon Owen y yo descubriéramos que hay de hecho diferencias en cómo se gestiona HPEN en SimCoupé respecto del SAM real. Él escribió un programa de test y comprobó que efectivamente en el SAM real HPEN se comporta de forma ligeramente diferente a como lo hace su emulador. Ambos actualizamos nuestros respectivos códigos, y eso podría ser la causa de que aparezca de nuevo el temblor, pero no las tengo todas conmigo.

EDITO: Ah, se me olvidaba comentar que suena bastante bajito, tengo que poner el volumen entre 3 y 4 veces más alto que antes (comparación con beeps)

Estoy en ello: de momento estoy probando con varios valores para el compresor, cambiando la relación de volumen entre el beeper y el SAA, etc.

- En el juego CRAFT! el título que son letras grandes en azul, la parte inferior de las letras se ve roja, cuando deberían ser azules enteras..

Me lo apunto para ver qué otra cosa he entendido mal de la documentación (y van...)

- En el Tetris, no recuerdo si ya lo comenté o no, pero bueno, faltaría el scroll de texto sobre banda gris en la línea inferior de la pantalla

Esto puede tener que ver con lo mencionado anteriormente sobre HPEN. Si resulta que es eso, creo que lo dejaré como estaba aunque no sea lo que hace el SAM real.

¡Qué lástima que el único core de Z80 que afirma ser cycle-exact está escrito en SystemVerilog y no en Verilog o VHDL! Tengo unas ganas de probarlo, a ver si así se solucionan los problemas de timings...

[Quest]

Gracias por todas las explicaciones.

Es una pena que esté tan poco documentado, en cierto modo al ser un sistema con una vida tan corta y tan pocos usuarios, podría entenderse.
Cuando estuve mirando lo del modo 3, no encontré absolutamente nada al respecto, con lo cual uno tiende a pensar que se comporta del mismo modo, con respecto a los bits más significativos para el color del píxel. Imagino que resolverlo habrá sido un trial-error, con la otra posibilidad que quedaba...

Con respecto a los registros de paginación xMPR, pasa un poco lo mismo. No se encuentra apenas nada, y cuando llegas al estupendo PDF que afirma ser el manual técnico no-oficial del SAM y ves en el índice una clara referencia a ellos, vas corriendo a la página correspondiente y... está vacia.

El tema del sonido faltante, bien podría ser por el tema de las envolventes que falta, no obstante no sé diferenciarlo simplemente por el sonido que sale. Seguiremos probando. Estaba pensando en pasar a cinta el Protracker, para poder generar cualquier tipo de sonido, trae un editor potentillo.

Respecto al core del Z80, imagino que te refieres al A-Z80 que ya estuvimos comentando en el hilo del ZX-UNO. Vi la conversación que llevabas con el autor en el foro del esxdos, y no avanzó el tema. No obstante, revisando el repositorio de Opencores http://opencores.org/project,a-z80 veo que está prácticamente todo en Verilog, salvo algunas cositas. El autor lo usa en una Cyclone-II de Altera. Hace tiempo vi (no recuerdo dónde, no lo guardé en favoritos, lo siento) alguna utilidad para convertir código sencillo de SVerilog a Verilog, y algunas pautas para hacer conversiones manuales. Si el trabajo no fuera mucho quizá merezca la pena...

Por cierto, si se te ocurre alguna cosa más (yo sigo mirando cosas útiles para volcar) que pueda resultar útil para el testeo o debug del core actual, dímelo y lo voy pasando a cinta, es por ahorrarte tiempo y que no tengas que hacer conversiones a cinta, mientras haces otras cosas (además de tener vida, comer, pasear, dormir, claro )

[mcleod_ideafix]

No obstante, revisando el repositorio de Opencores http://opencores.org/project,a-z80 veo que está prácticamente todo en Verilog, salvo algunas cositas.

Todo lo que sean archivos .sv o .vh son SystemVerilog, y de esos vi un montón en el repositorio...

Por cierto, si se te ocurre alguna cosa más (yo sigo mirando cosas útiles para volcar) que pueda resultar útil para el testeo o debug del core actual, dímelo y lo voy pasando a cinta, es por ahorrarte tiempo y que no tengas que hacer conversiones a cinta, mientras haces otras cosas (además de tener vida, comer, pasear, dormir, claro )

Puessssss.... lo de los trackers estaría bien para terminar de pulir el SAA1099

-- Actualizado 10 Ago 2015, 14:58 --

He actualizado el core TEST 3 con unos añadidos al SAA1099 para mejorar el rango dinámico: en los dos mezcladores finales hay un sistema de compresión gobernado por una pequeña ROM de 256 posiciones, que guarda los valores de "gamma" para aplicar al sonido. Aún no tenemos envolventes, sorry.

Se puede cambiar esta ROM generando otra con el programa gen_curva_compresor.c En él hay una constante GAMMA que está ahora mismo al valor 0.75. El rango de valores posibles es 0 < GAMMA <= 1. Si es 1, no hay compresión, y la mezcla es completamente lineal. Si se acerca mucho a 0, habrá mucha compresión.

Que haya mucha compresión significa que cuando la música en origen es muy bajita, el sistema la amplifica mucho, y a medida que su volumen sube, el factor de amplificación es menor hasta que llega un punto en que no se amplifica nada y se queda como está. La cantidad de amplificación en valores bajos depende de este valor GAMMA: cuanto más cercano a 0, más amplificación.

Podeis probar por tanto variando dentro de sus límites el valor de GAMMA, ejecutando de nuevo el programa, que creará un fichero .hex con los valores para la ROM, y en pantalla aparecerá la relación entre valores de entrada (de 0 a 186) y valores de salida (de 0 a 255). En la entrada, aunque es de 8 bits, nunca habrá valores mayores de 186, ya que son 6 canales los que se mezclan, con un rango de 0 a 31 cada uno, lo que nos da un valor máximo de entrada de 31*6 = 186. Por eso en la ROM los valores que corresponden a las posiciones 187 a 255 valen todos 255: en realidad el sistema nunca llega a usarlos.

Sobre los fallos en Tetris y en el efecto truecolor de SCDIT... no sé qué he hecho con VMPR o con HPEN o con LPEN o vaya usté a saber, que no consigo que se vuelva a ver la franja con el texto desplazándose. Tengo que tirar de repositorio a ver qué hice o qué no hice en el core en el que sí funcionaba eso.

Con todo, es usable, y jugable ¡Para llevar 10 días escribiendo la descripción en Verilog tampoco se puede pedir más! (bueno, sí, que alguien traduzca el A-80 a Verilog, o al menos, a EDIF)

[Quest]

Buenas,

Primero de todo siento no haber podido volcar el ProTracker II, tras muchos intentos infructuosos, ha sido totalmente imposible para mi. Resulta que la única copia disponible de este programa está volcada en un formato de disco extendido del .DSK que soporta la reproducción de ciertas protecciones anti-copia. Este tracker tiene protección anti-copia, y no he sido capaz de convertirlo Ni siquiera hay programas capaces de abrirlo, salvo el propio SimCoupé.

No veo alternativas tan potentes para el tema del sonido, pero sigo en ello.

Por cierto, que he visto que se ha avanzado con el tema de las envolventes en la implementación del SAA1099

Te agradezco todo el currazo que te estás pegando con este core, es alucinante. Seguramente en la versión final del crowfunding del ZX-UNO, si al final hay multiboot, éste core sin duda será el que le ponga junto al de Spectrum. Y si no hubiera multiboot, tendré un ZX-UNO exclusivamente para él

Con respecto al tema del SAA1099 de nuevo, he comprobado que con los nuevos añadidos respecto a las envolventes, se ha perdido algo en el sonido, puesto que hay cosillas que ahora no se escuchan, pero a cambio se escuchan nuevas aunque todavía le falta pulirse, es la primera implementación de este chip de sonido en FPGA que se hace! es una pasada, increíble . Seguro que al final queda fino finísimo!

Otra cosa, imagino que no, porque en el código del asic.v no lo veo, pero por si acaso pregunto, ¿Tenemos implementada la lógica del ASIC para los puertos DISC1 y DISC2? En caso de que no, ¿cuánto costaría hacer la implementación? me refiero únicamente a hacer el mismo comportamiento que tiene el ASIC para el I/O de señales en esos puertos. Si no es demasiado complicado, cuando en algún momento se pueda hacer, aunque sea para el puerto DISC2 + los 2 integrados del Atom Lite. Nada más. Lo quiero simplemente para mapear luego los pines de salida del Atom al puerto de expansión del ZX-UNO y ya por mi cuenta me encargaría de hacer las conexiones a una CF para hacer pruebas más rápidas cargando desde la CF. Actualmente cada vez que quiero comprobar como suena una cosa u otra, (sobre todo con la demo SCDIT) pues hay que esperar unos 10 mins. Además, una vez hecha esa lógica del ASIC, servirá para implementar más adelante la carga con la SD, que eso ya será otra histora más complicada.