ZX-Uno prototipo 2: seguimos dándole caña

[Hark0]

Habrá que añadir un boli BIC al "Kit ZX-Uno"....

[na_th_an]

Pues si me decís qué restricciones imponen estos cacharros podría tenerlo en cuenta. De todos modos me resulta muy raro porque mi conocimiento no es para nada profundo, no hago cosas hiper raras que expriman el hardware aprovechando detalles de diseño y bla bla bla. De hecho, programo en C, con lo que casi toda la mierda la hace el compilador.

Si me decís qué juegos funcionan y qué juegos no, a lo mejor, por deducción, podríamos averiguar qué ocurre.

Por ejemplo, casi todos nuestros juegos de 128K tienen la configuración del modo IM2 idéntica, pero Maritrini es diferente (tiene la tabla de salto y los vectores en otro sitio).

Lo raro es que Maritrini no está hecho con la churrera. De hecho ni siquiera emplea splib2 para nada, como el resto de nuestros juegos. Los otros dos que has dicho (Pentacorn y el nuevo de Dogmole) son juegos de 128K.

¿Todos los que no funcionan son juegos de 128K?

Ninjajar! tiene un cargador en código máquina. ¿Será que estos cachivaches no se llevan bien con paginar desde BASIC? Podría ser el quid de la cuestión. Los demás juegos paginan desde BASIC para ir cargando los bloques. A lo mejor estos cachivaches introducen alguna compatibilidad que hace que no se pagine bien, o que el sistema se quede inestable o corrupto.

La solución sería emplear las técnicas de Antonio Villena para generar cargadores en C/M para estos juegos de 128K, tal y como hicimos con Ninjajar! (que decís que sí que funciona).

[radastan]

Si me decís qué juegos funcionan y qué juegos no, a lo mejor, por deducción, podríamos averiguar qué ocurre.

Así para empezar, funcionan:

- Ninjajar
- Misco Jones
- Nightmare on Halloween

No funcionan:

- Dogmole Tuppowski - Las Nuevas Aventuras
- Maritrini Monster Slayer
- Pentacorn Quest

[na_th_an]

O sea, todos los que no funcionan son juegos de 128K con cargador en BASIC, al menos con la lista que has dado. Los que sí funcionan son o bien de 48K o bien de 128K pero con cargador en C/M.

La solución entonces es seguir el tutorial de Antonio para generar cargadores en C/M. Con la primera versión vale, no hace falta llegar a comprimir.

[mcleod_ideafix]

Los juegos que no funcionan no lo hacen porque sea un ZX-Uno. Lo que pasa es que el cargador asume que estamos en un 128K con su ROM de 128K, y cuando el DivIDE o el DivMMC están en uso, eso no es así, sino que es la ROM de 48K la que está funcionando.

¿Y qué pasa? Pues que la ROM del 48K no inicializa ni hace nada con la variable del sistema BANK_M (23388). Lo malo es que los cargadores de 128K para cambiar de página asumen que en esa dirección hay un backup del último valor enviado al puerto 7FFDh y lo usan. En ese momento, adios cargador y adios juego.

O sea que estos juegos (y algunos otros que he probado como el SPLATTR o demos como "We Are Spectrum" de Ate-Bit) fallan al cargarlos desde un DivMMC o DivIDE por esta razón, sea un ZX-Uno o un Spectrum de Sinclair. O un emulador al que se ha arrancado en modo 128K, se ha pasado a 48K con un RANDOMIZE USR 0 y después se ha intentado cargar el juego desde un TAP.

La solución es muy sencilla: antes del LOAD "", haced un POKE 23388,16 . Si se usa ESXDOS, que carga el juego nada más seleccionarlo, dejarlo que se resetee (o lo reseteais vosotros con Ctrl- Alt-Supr), haceis el POKE 23388,16, rebobinais con la orden de ESXDOS .tapein -r (versión ultrarrápida del boli bic ¡no os olvideis del puntito al principio!) y por último LOAD ""

Haciéndolo así, me han funcionado los tres

En juegos que funcionen en 128K y que tengan un cargador, en BASIC o C/M, que se fía de lo que hay en la variable del sistema BANK_M puede ser útil añadir esta línea (en el cargador BASIC, antes de cargar nada más):

Código: Seleccionar todo

IF PEEK 23388=0 THEN POKE 23388,16

En un 48K, esta dirección pertenece al buffer de la impresora y estará a 0. En un 128K, durante la ejecución de un comando como PEEK, la ROM en servicio es la ROM 1 (o ROM 3 en un +2A/3) y esta variable del sistema no contendrá 0, sino otra cosa (16 lo más probable pero no tiene por qué). Si la variable resulta ser 0, entonces hemos arrancado en 48K y es seguro darle a esta variable el valor 16 ya que para pasar de 128K a 48K ese es el valor que se le ha quedado al puerto 7FFDh.

-- Actualizado 16 May 2015, 05:47 --

Hablando de otra cosa: me he llevado gran parte de la noche descifrando la descripción VHDL del T80. Ya sabeis, la versión softcore del procesador Z80 que tiene el ZX-Uno.

Como sabeis, porque lo hemos comentado más de una vez, el T80 no es del todo compatible ciclo a ciclo con un Z80. Durante las pruebas del primer prototipo ya detectamos algunas diferencias gordas, tales como por ejemplo el manejo de los flags en las instrucciones que acceden a los registros I y R. Solucionadas esas primeras inconsistencias, juegos como el Kings Valley ya funcionaron

Pero hay algunas demos y tests técnicos que se resisten. Una de las demos técnicas es el visor del modo HAM256 y HAM8x1 de Andrew Owen. Con el addon del Z80 real se veía claro que el fallo era del T80 y no de la implementación de la ULA u otra cosa.

Desde el principio venía sospechando yo que las temporizaciones de la señal IORQ no eran correctas. De esto me di cuenta al depurar la contención de la ULA, y veía que IORQ se comportaba igual que MREQ cuando no debe ser así. Como mi VHDL-kung-fu no estaba (ni está) muy fino, no tuve cabeza para meterme en la descripción del T80, que no está en Verilog sino en VHDL.

Hoy me ha dado por hacer alguna prueba más, y he visto que por ejemplo, la instrucción OUTI/OUTD/OUTIR/OUTD funcionan como deben (pese a mis también sospechas) peeeero INI/INIR/IND/INDR no lo hacen. Al arreglar este grupo de instrucciones he comprendido, más o menos, cómo funciona la máquina de estados del T80, y ya me he emocionado buscando más fallos.

La generación de IM 2 en principio parece que fallaba pero no, la han corregido (y se nota que hay código comentado). Entonces es cuando me he atrevido con IORQ y creo que lo he conseguido

Así por tanto, se ha actualizado el core del test15 con los cambios realizados al core T80. Ahora he podido comprobar que funcionan con temporizaciones exactas los siguientes programas, que antes no lo hacían

Demos técnicas (los dos visores de Andrew)
- HAM256
- DEMOHAM8

Demos
- Megalomania (debe ejecutarse en modo 128K, es decir, dando antes el comando .zxunocfg -t128 -cy ). Observad la parte en la que hay una ventana grande con scroll a la derecha, otra pequeña con scroll a la izquierda, sobre un fondo de cuadros de ajedrez.... ¡que cubre también el borde superior! Esa parte, la del borde superior, se veía antes de pena (probad a ejecutarla con temporizaciones de 48K y vereis a qué me refiero). También la última parte, con el cartel de TERMINATOR en múltiples colores no se veía bien. Hay dos rayas rojas que van de lado a lado de la pantalla, incluidos los bordes, que no coincidían. Ahora sí lo hacen
- Nyan Cat (la versión para 128K/+2 gris. Debe ejecutarse en modo 128K, es decir, dando antes el comando .zxunocfg -t128 -cy )

Si hay algún otro programa o demos que no se muestra bien, comentadlo a ver si se ha arreglado con esta revisión del core... o no :\

[Quest]

Así por tanto, se ha actualizado el core del test15 con los cambios realizados al core T80. Ahora he podido comprobar que funcionan con temporizaciones exactas los siguientes programas, que antes no lo hacían

Madreeeee

Increible, por fin lo has logrado. Wow!

Que lastima que no esté en casa ahora. En cuanto llegue esta tarde me pongo a grabar el nuevo core y a probar a saco.

Que grande!

[Haplo]

Fantástico McLeod!
Aprovecho para preguntar si ya es posible actualizar el core desde la microsd, sin tener que usar un programador, porque hay gente que no lo tiene (Hark0, por ejemplo).
Recuerdo algo que comentó Antonio sobre eso hace algún tiempo pero no estoy seguro de si se solucionó el tema.

[antoniovillena]

Fantástico McLeod!
Aprovecho para preguntar si ya es posible actualizar el core desde la microsd, sin tener que usar un programador, porque hay gente que no lo tiene (Hark0, por ejemplo).
Recuerdo algo que comentó Antonio sobre eso hace algún tiempo pero no estoy seguro de si se solucionó el tema.

Sí se puede. Tarda bastante en cargar porque es vía EAR pero es factible.

[na_th_an]

En juegos que funcionen en 128K y que tengan un cargador, en BASIC o C/M, que se fía de lo que hay en la variable del sistema BANK_M puede ser útil añadir esta línea (en el cargador BASIC, antes de cargar nada más):

Código: Seleccionar todo

IF PEEK 23388=0 THEN POKE 23388,16

Me lo apunto para futuros lanzamientos. Gracias.

[Quest]

Si hay algún otro programa o demos que no se muestra bien, comentadlo a ver si se ha arreglado con esta revisión del core... o no :\

Bueno, pues he estado bastante rato probando cosas con el nuevo core, y parece ir todo bien ¡Has dado con la clave del fallito del T80, sin duda!

Para mi gusto este es un avance muy significativo. La máquina ULA+ definitiva y económica se llama ZX-UNO

Al margen de este tema, probando cosas me he encontrado con alguna cosilla, no relativa al T80, y aprovecho para comentarla. Seguramente tampoco tiene que ver con el ZX-UNO:

- No se si ya es conocido (supongo que si, pero yo no lo había visto), pero en la demo del HAM8x1, con los timings de 128 salge algún glitch en las imágenes (esto ocurre también con el core Z80 externo, así que es independiente de la CPU entiendo). Con los timings de 48k se ve bien. Muestra del glitch (ver líneas horizontales que no deberían estar):



- Respecto a la carga de juegos problemáticos con DivMMC/EXDOS, efectivamente la solución del poke es totalmente efectiva y de rebote me he encontrado con que una demo que siempre trato de cargar en el ZXUNO (porque me gusta bastante) y nunca consigo que funcione bien, resulta que también es incompatible con DivMMC/ESXDOS: Paralactika. Cargando por EAR funciona perfectamente, sin cuelgues, mientras que con ESXDOS no inicia, o se cuelga en puntos aleatorios o sale sin sonido, etc. El tema es que no se soluciona con el poke (de hecho parece empeorarlo con un error 100:1), así que imagino que las incompatibilidades serán más profundas. Esto no tiene que ver realmente con el ZXUNO según yo entiendo, pero lo comento por si acaso.

Sigo probando cosillas