Proposición de gráfica externa para ZX Spectrum

[antoniovillena]

EDITADO: Vaaaaale, he cogido el ejemplo de Bob esponja, le he dado al enter, he cargado y ya me lo coje.

Noooo!!!!! Tienes que partir del emulador a secas, vamos de este enlace:

http://jbacteria.retrolandia.net/48

Y arrastrar un archivo hacia la ventana del emulador (dentro del recuadro de 256x192, en el borde no vale). Si el archivo es .SNA o .Z80 carga directamente. Si es un .TAP aparentemente no hace nada, pero luego cuando pones LOAD""+Enter carga lo que hay en la cinta.

[radastan]

Buenas radastan. Mientras zx81 te implementa el modo en su JSpeccy y no tengas el ZX-Uno, te he creado un modo radastaniano en mi emulador jbacteria.

Teniendo en cuenta que apenas estoy empezando a mirar todo lo que tengo que tocar y que jbacteria es tan bueno como cualquier otro, no veo ya la necesidad de modificar nada en JSpeccy. Total, de momento solo se trata de que radastan pueda hacer pruebas sobre algo emulado. Si finalmente el ZX-Uno sale adelante, puede que incluso otros emuladores lo implementen (por ejemplo, el autor de Spectaculator solo está dispuesto a implementar cosas que existan físicamente, por eso no soporta ULAplus).

Ha estado rápido Antonio esta vez..

Hombre... no es complicado implementar el modo: no tiene contención, es lineal, etc. Es más, seguro que Antonio te dice como implementarlo con poco esfuerzo.

Lo digo porque me gustaría seguir usando tu emulador, sin ofender a Antonio y su excelente emulador.

[antoniovillena]

En mi emulador ha sido muy sencillo porque es javascript. Pongo aquí las modificaciones por si sirven de algo. Lo primero es detectar cuando se activa el modo radastaniano, esto se hace en el momento en que se escribe en el puerto, antes estaba esto:

Código: Seleccionar todo

  else if( addr == 0xff3b ){
    if( ula==0x40 )
      paintScreen= val&1 ? paintUlap : paintNormal;


Ahora esto otro:

Código: Seleccionar todo

  else if( addr == 0xff3b ){
    if( ula==0x40 )
      paintScreen= val&1 ? (val&2?paintRadas:paintUlap) : paintNormal;


Por último hay que crear una función nueva, paintRadas, que se encargue de pintar toda la pantalla en el modo Radastaniano, es así de sencilla:

Código: Seleccionar todo

function paintRadas(){
  for ( o= 0
      , u= 0x4000
      ; u < 0x5800
      ; o+= 0x400)
    for ( k= 0
        ; k < 0x40
        ; k++
        , o+= 16)
      col= m[u++],
      t= ulap[col>>4],
      eld[o  ]= eld[o+4]= eld[o+0x400]= eld[o+0x404]= t[0],
      eld[o+1]= eld[o+5]= eld[o+0x401]= eld[o+0x405]= t[1],
      eld[o+2]= eld[o+6]= eld[o+0x402]= eld[o+0x406]= t[2],
      t= ulap[col&15],
      eld[o+8 ]= eld[o+12]= eld[o+0x408]= eld[o+0x40c]= t[0],
      eld[o+9 ]= eld[o+13]= eld[o+0x409]= eld[o+0x40d]= t[1],
      eld[o+10]= eld[o+14]= eld[o+0x40a]= eld[o+0x40e]= t[2];
  ct.putImageData(elm, 0, 0);
}


En realidad podría haberlo complicado más para conseguir mayor velocidad, cambiando la resolución del canvas. Pero para no liarla lo que hago es copiar el pixel que toca a los 4 píxeles que se corresponden en resolución 256x192 y mantener siempre el mismo tamaño del canvas.

[Hark0]

Acabo de catar el link moco.tap....que habia perdido la pista de este hilo

Y FUNCIONA DE PERLAS, que estoy en la tabla y me voy al wc a orinar porque he flipado en colores!!!

Antonio, lo tuyo es de juzgado de guardia.... ERES UN MONSTRUO!!!


Preguntas (dando el coñazo como siempre):

- ¿puedes poner el src de la demo moco @Radastan?

- Es posible una versión de escritorio del emulador? y me cargo fuse pero YA!!! (trabajar con apps en navegador en el ordenador no me convence). Sino la rom reset & play que comentas? leches.rom?


Cada dia flipo más con vosotros, qué suerte de conocimientos! Bravo!

[antoniovillena]

:shock: Acabo de catar el link moco.tap....que habia perdido la pista de este hilo

Y FUNCIONA DE PERLAS, que estoy en la tabla y me voy al wc a orinar porque he flipado en colores!!!

Antonio, lo tuyo es de juzgado de guardia.... ERES UN MONSTRUO!!!

No es nada nuevo, este emulador lo hice hace tiempo. Es poco preciso (por ejemplo no emula contención y vuelca la pantalla de golpe) pero es rápido y muy útil para hacer experimentos. Ya los hice con el scroll hardware. Si quieres un emulador javascript más exacto, prueba el QAOP JS.

Preguntas (dando el coñazo como siempre):

- ¿puedes poner el src de la demo moco @Radastan?

No es una demo, es una pantalla estática. El código lo escribió McLeod y está en el repositorio del ZX-Uno, archivo software/modo_radastan/visor128x96.asm. Para no complicarse la vida con un conversor de imagen, lo que hace es incluir el binario del archivo BMP y leer línea a línea hacia atrás (porque el formato BMP funciona así).

- Es posible una versión de escritorio del emulador? y me cargo fuse pero YA!!! (trabajar con apps en navegador en el ordenador no me convence). Sino la rom reset & play que comentas? leches.rom?

Cada dia flipo más con vosotros, qué suerte de conocimientos! Bravo!

Supongo que sí, pero no conozco ningún entorno que compile js. Seguro que hay algo (Adobe AIR o similares), pero con la cantidad de emuladores nativos no tiene mucho sentido. ¿Por qué no te convence trabajar con un emulador bajo el navegador? Se pueden hacer más cosas de las que crees.

[mcleod_ideafix]

Ahora a calentarme la cabeza con un programa que me convierta un PNG con tiles o sprites a código (dos pixels por byte) incluyendo la plaeta.

Si el PNG lo grabas como BMP de 16 colores sin compresión, ya estará en el formato radastaniano. Sólo tendrás que cambiar la paleta a una que tenga 3 bits de rojo, 3 de verde y 2 de azul. De hecho, los visores que permiten ver las imágenes que Antonio ha puesto no hacen más que cargar un BMP de 128x96 con paleta. La paleta es lo que el visor adapta antes de mostrártela. En la sección de software del repositorio tienes un directorio llamado "modo_radastan". Dentro de él tienes el código fuente del visor. Verás que lo que hace es incluir como parte del código el fichero completo BMP

[ZX-81]

Buenas radastan. Mientras zx81 te implementa el modo en su JSpeccy y no tengas el ZX-Uno, te he creado un modo radastaniano en mi emulador jbacteria.

Teniendo en cuenta que apenas estoy empezando a mirar todo lo que tengo que tocar y que jbacteria es tan bueno como cualquier otro, no veo ya la necesidad de modificar nada en JSpeccy. Total, de momento solo se trata de que radastan pueda hacer pruebas sobre algo emulado. Si finalmente el ZX-Uno sale adelante, puede que incluso otros emuladores lo implementen (por ejemplo, el autor de Spectaculator solo está dispuesto a implementar cosas que existan físicamente, por eso no soporta ULAplus).

Ha estado rápido Antonio esta vez..

Hombre... no es complicado implementar el modo: no tiene contención, es lineal, etc. Es más, seguro que Antonio te dice como implementarlo con poco esfuerzo.

Lo digo porque me gustaría seguir usando tu emulador, sin ofender a Antonio y su excelente emulador.

Ya he comentado alguna vez que tan simple no es, porque hay que encajar eso con el código que ya existe y hay muchas cosas montadas de tal manera que la emulación de la pantalla del Spectrum vaya tan rápida como sea posible.

Repasando lo que escribió mcleod_ideafix en la página 5 de este hilo me han surgido dudas que no he visto planteadas ni resueltas en el resto del hilo. Las plantearé, porque puede que, de paso, tenga alguna idea que resulte útil. Primero, las suposiciones:

• Se está emulando algo similar al 128k, porque tenemos dos pantallas con la posibilidad de tener 4, dependiendo del bit correspondiente de 0x7FFD y del out al puerto 0xff. Si conectamos el ZX-Uno a un 48k, lo convertimos en un 128k hipervitaminado.
• Cuando se dice que el Z80 no tiene contención se refiere tanto a la memoria como a la I/O, incluido el puerto de ULAplus que normalmente la tiene y que en este caso tampoco la tendría.
• Los colores se sacan de la primera paleta (la 0) de ULAplus.

Y ahora, las dudas:

• En el Spectrum se hacen dos lecturas de la RAM de video, una para sacar el bitmap y otra para sacar el atributo y con eso se pintan 8 pixeles a razón de dos por ciclo de reloj. Ahora, esas dos lecturas son de direcciones consecutivas y con eso se pintan 4 pixeles del doble de tamaño. Esas dos lecturas no sé si verlas como una unidad indivisible, como en el Spectrum, o como dos independientes (en el 48k son una unidad indivisible).
• Así como el doble ancho del pixel no creo que afecte a nada más, la doble altura sí, porque cada línea de scan es independiente en sí misma y, supongo, que mcleod_ideafix lee dos veces cada pixel para pintar físicamente cada una de las líneas. Lo planteo pensando en los efectos de color en alta resolución donde se cambian atributos al vuelo, para que se pinten colores diferentes en cada línea de scan del mismo carácter. Ello además me da pie a proponer dos cosas a elegir (como los bolis BIC):
  
  1.- que los colores de las líneas pares salgan de la paleta 0 y las impares de la 1 (posibilidad de doble resolución de color, por llamarlo de algún modo), o bien
  2.- que los colores salgan de la paleta seleccionada vía un out a algún registro de ULAplus. Con un solo OUT entre líneas podemos sacar los colores de cualquiera de las 4 paletas y conseguir efectos de color más chulos.

Bueno, creo que para ponerse en plan preguntón he comenzado bien. Aclarar que no pregunto por preguntar. La estructura del emulador está hecha para soportar todas las perrerías que se hacen con la pantalla sin tener casos particulares o preocuparse por lo que se está ejecutando. La mayor parte de esa estructura tengo que mantenerla, con todo lo que supone o se me monta un pifostio del carallo bendito...

[mcleod_ideafix]

Repasando lo que escribió mcleod_ideafix en la página 5 de este hilo me han surgido dudas que no he visto planteadas ni resueltas en el resto del hilo. Las plantearé, porque puede que, de paso, tenga alguna idea que resulte útil. Primero, las suposiciones:

• Se está emulando algo similar al 128k, porque tenemos dos pantallas con la posibilidad de tener 4, dependiendo del bit correspondiente de 0x7FFD y del out al puerto 0xff. Si conectamos el ZX-Uno a un 48k, lo convertimos en un 128k hipervitaminado.

Dado que ya no estamos hablando de una tarjeta que se le pincha a un Spectrum, sino de un modo nativo del ZX-Uno, ya no tiene sentido hablar de conectar el ZX-Uno a nada. El ZX-Uno ES el ordenador. El ZX-Uno es un ordenador de 128K que además implementa los modos nativos Timex. Si JSpeccy no emula Timex, no tienes que preocuparte para nada del puerto $FF. Simplemente no estará implementado. Dudo mucho que Radastan necesite siquiera más de una página de video para sus juegos, mucho menos cuatro.

Cuando se dice que el Z80 no tiene contención se refiere tanto a la memoria como a la I/O, incluido el puerto de ULAplus que normalmente la tiene y que en este caso tampoco la tendría.

Exacto. Nada de contención. Ni mijita. A ningún puerto. A ninguna zona de memoria.

Los colores se sacan de la primera paleta (la 0) de ULAplus.

Correcto.

• En el Spectrum se hacen dos lecturas de la RAM de video, una para sacar el bitmap y otra para sacar el atributo y con eso se pintan 8 pixeles a razón de dos por ciclo de reloj. Ahora, esas dos lecturas son de direcciones consecutivas y con eso se pintan 4 pixeles del doble de tamaño. Esas dos lecturas no sé si verlas como una unidad indivisible, como en el Spectrum, o como dos independientes (en el 48k son una unidad indivisible).

Aquí, dado que no hay memoria dinámica, las lecturas son siempre independientes. Se realizan mucho más rápidamente que en el Spectrum normal. En el Spectrum normal lees 4 bytes en 6 ciclos de reloj de Z80 y dejas 2 sin contención. En el ZX-Uno durante el modo radastaniano, se lee un byte, me parece recordar, que cada dos ciclos de reloj. De hecho quité la contención porque, de dejarla, sería una contención mucho más restrictiva que la del Spectrum.
la secuencia sería más o menos así (los ciclos son de CPU, que equivalen a 2 ciclos de ULA, es decir, 2 píxeles usando 256 píxeles horizontales):
Ciclo 0: leo un byte (dos píxeles)
Ciclo 1: pinto el primer píxel (que ocupará el espacio de 2 píxeles originales)
Ciclo 2: pinto el segundo pixel mientras leo el siguiente byte
Ciclo 3: igual que el ciclo 1.

Por supuesto, cuando termino una línea de exploración, la siguiente se pinta usando exactamente la misma información, con lo que sí, es posible cambiar la paleta o el contenido de esa línea y tendrías más resolución vertical.

1.- que los colores de las líneas pares salgan de la paleta 0 y las impares de la 1 (posibilidad de doble resolución de color, por llamarlo de algún modo), o bien
2.- que los colores salgan de la paleta seleccionada vía un out a algún registro de ULAplus. Con un solo OUT entre líneas podemos sacar los colores de cualquiera de las 4 paletas y conseguir efectos de color más chulos.

Este modo se ha pensado fundamentalmente para crear juegos sin attribute-clash y que tengan, digamos, un look nuevo en el Spectrum, sin gastar CPU. Se pueden realizar virguerías del estilo que comentas, pero precisamente propuse a Radastan cosas como un modo de 128x192 y lo rechazó, precisamente porque ya no sería algo "simple" y además ocuparía más memoria. Cambiar el hardware para que en cada línea use direcciones diferentes y así tener una resolución real de 128x192 es trivialísimo. Las cosas que propones, en hardware, no son tan triviales, ya que cada multiplexor añadido en la ruta de datos "cuesta" espacio en la FPGA y se come tiempo de propagación de los datos.

[Hark0]

Vale, acabo de catarlo en el Mac... y funciona en Safari...

Una cuestión... ¿no habría que adaptar la fuente al modo de pantalla?

Al hacer un BREAK y volver al Basic se corrompe la pantalla, aunque al hacer un LIST esta en "modo 48" (la pantalla)... un GOTO 40 y... perfecto

-- Actualizado 02 May 2014, 07:46 --

Supongo que sí, pero no conozco ningún entorno que compile js. Seguro que hay algo (Adobe AIR o similares), pero con la cantidad de emuladores nativos no tiene mucho sentido. ¿Por qué no te convence trabajar con un emulador bajo el navegador? Se pueden hacer más cosas de las que crees.

No te lo niego, solo comentaba si lo tenias pensado... por mi no hace fata que te lies... si hay "que tirar" la cinta a un navegador... SE LE TIRA!

[antoniovillena]

No es que se corrompa, es que al estar usando la misma zona de memoria para representar la pantalla en modo Radastaniano, si vuelves al modo normal (el programa sale del modo Radastaniano y retorna al BASIC) ves la pantalla mal codificada. Como no se usa la zona de atributos lo ves en blanco y negro. Es normal, también pasaba en el ZX-Uno. El programa tiene un cargador en BASIC, funciona tanto el GO TO 40 como el RUN porque una vez se acaba la cinta se vuelve al comienzo de esta.