Scroll por hardware

[antoniovillena]

Z80user, los 24 bytes son necesarios si quieres dar "continuidad" a los tiles de fondo. Sería más sencillo (a la hora de la implementación hardware) usar en la columna 32 los atributos de la columna 0, pero esto te limita a que el juego tenga que ser monocromo. Y repito, no sirve de nada ocultar (poner la tinta del mismo color del fondo) las columnas 0 y 32, porque mostraríamos una ventana que continuamente se está desplazando. Te recomiendo que pruebes el ejemplo basic para ver el funcionamiento exacto.

En cuanto a arreglar un spectrum con ULA averiado, la solución que propones es más práctica de hacer, pero en cuanto a sencillez y precio no hay nada más fácil que un reemplazo directo del chip.

Como bien explicas es posible jugar a juegos diseñados con scroll hardware en máquinas con ULA normal. Los sprites estarían avanzando y retrocediendo todo el rato, dando la percepción de movimiento suave. Con scroll hw nuestro mario estaría quieto en el centro de la pantalla y el fondo sería el que se mueve. Sin scroll, estaría en el centro, se desplazaría 1 pixel a la derecha en cada frame, y al completar 8 frames retrocedería 8 pixels del tirón. Otro efecto secundario es que en la columna cero se vería basura (lo que en teoría debe aparecer en la columna 32).

Ya he dicho que la demo está mal hecha más que nada por las prisas. Osea que no se debería ver la última columna corrompida, y en caso de ejecutarlo en un zx 128k la "morralla" debe aparecer sólo en la columna 0.

Edito: Si los 24 bytes adicionales de atributos complican mucho el diseño lo más sencillo es mantener la rejilla de atributos estática, pero la desventaja de este tipo de scroll es que tendrías que lidiar con el atribute clash, dejando huecos entre tiles para que no se te entremezclen los colores.

[flopping]

Hola Z80user, ¿tienes los esquemas del speccybob y del speccybob 128?, es que no los encuentro, ya que parece que han borrado todo su rastro, si me pudieras pasar una copia de ellos te lo agradeceria, si tambien hay placas diseñadas y demas, seria perfecto.

Otra cosa, me quiero grabar las gal del divide, en teoria tengo un programador que lo hace y tambien tengo unas que compre ya programadas, ademas de los ficheros JED de la web del divide, pero no consigo copiarlas o grabarlas correctamente, ya que al hacer la lectura me dice que no son iguales, ¿hay algun problema al grabar los ficheros o leer una y luego grabarla en otra, o es que estoy haciendo algo mal?

Gracias por tu ayuda.

[Z80user]

Con los 24 bytes adicionales, me referia, a que es mejor hacer algo que pueda funcionar en un Spectrum con una ULA normal, de la misma forma que funcione con una nueva ULA con sroll por hardware, o que al menos no varie en esceso la forma en que se comportase, ya que los juegos habria que tener las rutinas de impresion duplicadas (que hagan dos cosas de forma similar)
El TAP no se como descarglo, lo veo casi como un video, por lo que no veo mas alla de lo que puedo intuir.
El scroll, si esta referido al desplazamiento del atributo, con respecto al bitmap.
NOTA: SH = Scroll por hardware, N = numero del desplazamiento en el registro
Uno de los problema de implementacion, en la parte del desarollador, seria que los atributos rotarian en toda la pantalla, si hay un marcador, este tendria que ser monocromatico.
Para solucionarlo, utilizar un par de nibbles mas, para indicar en que columna empieza el efecto, y en que columna acaba, por defecto que esten a un valor no valido, 24 o mayor. En hardware serian 2 comparadores 2 nibbles y un flip flop JK.

En el caso del Mario, y los enemigos, segiriamos teniendo Color Crash, lo unico que haria el SH seria eliminar el color crash del fondo de la pantalla, pero no asi de los personajes.
En la demo de 128K, cuando escribes, los pixels, aparecen en la derecha de la pantalla (los de la 1º letra)
Para solucionarlo, elimina 8 pixels de la 1º columna, luego pinta el 1º pixel que toque,

FOR x=0 TO 7
- pixel N+x = posicion 8+x, atributo 8+x
NEXT x
En resumen, retrasar 8 pixels, lo que tardaria en pintarle el pixel N, manteniendo los atributos en su lugar en la pantalla
Coste en hardware 1 buffer de 8 bits, 3 bits, para indicar el desplazamiento y 1 bit para indicar si esta activo, 1 comparador de 3 bits, 1 OR o AND, para forzar a segir pintando el BORDER y 1 NOR de 5 entradas (para saber que estamos en la 1º columna y hay que segir pintando el BORDER), asi a groso modo segun el esquema del speccybob.

Para aprobechar la 1º columna, los 24 bytes, los utilizaria para los atributos que entrasen, desde la izquierda de la pantalla, asi tendriamos los atributos precargados,pudiendo mantener los ciclos del Spectrum real sin mayor problema. En lugar de introducirlos por la derecha.

Hola Z80user, ¿tienes los esquemas del speccybob y del speccybob 128?, es que no los encuentro, ya que parece que han borrado todo su rastro, si me pudieras pasar una copia de ellos te lo agradeceria, si tambien hay placas diseñadas y demas, seria perfecto.

Si los esquemas los tengo, Julio hizo un SpeccyBob en 3 placas, por lo que el diseño de las placas, el se que lo tiene hecho, en 3 placas apilables
Si lo quieres, dime tu e-mail y te lo mando (Si alguno mas lo quiere, lo mismo, que me deje un mensaje)

Otra cosa, me quiero grabar las gal del divide, en teoria tengo un programador que lo hace y tambien tengo unas que compre ya programadas, ademas de los ficheros JED de la web del divide, pero no consigo copiarlas o grabarlas correctamente, ya que al hacer la lectura me dice que no son iguales, ¿hay algun problema al grabar los ficheros o leer una y luego grabarla en otra, o es que estoy haciendo algo mal?

Con las GAL/PAL no se demasiado, pero con los PIC cuando lso grababa, la palabra de configuracion la escribia despues de grabarlo, puede que tengan algo, por lo que no se puedan leer despues de escribirse.

[antoniovillena]

Con los 24 bytes adicionales, me referia, a que es mejor hacer algo que pueda funcionar en un Spectrum con una ULA normal, de la misma forma que funcione con una nueva ULA con sroll por hardware, o que al menos no varie en esceso la forma en que se comportase, ya que los juegos habria que tener las rutinas de impresion duplicadas (que hagan dos cosas de forma similar)

Sí, estos 24 bytes simplemente no se verían en una ULA normal. Tampoco se ven en una ULA modificada si número de desplazamiento del scroll está a cero.

El TAP no se como descarglo, lo veo casi como un video, por lo que no veo mas alla de lo que puedo intuir.

De aquí:
http://jbacteria.antoniovillena.es/games/hwscdemo.tap
Y si quieres el código fuente lo tienes aquí:
http://antoniovillena.es/upload/hwscdemo.zip

El scroll, si esta referido al desplazamiento del atributo, con respecto al bitmap.
NOTA: SH = Scroll por hardware, N = numero del desplazamiento en el registro
Uno de los problema de implementacion, en la parte del desarollador, seria que los atributos rotarian en toda la pantalla, si hay un marcador, este tendria que ser monocromatico.

Sí, el scroll tal y como está te desplaza toda la pantalla, por tanto si quieres escribir algo como un marcador, la rutina que lo pinta tendría que tener en cuenta N y rotar el carácter. Y hacerlo rápido (tener todas las rotaciones de los caracteres en memoria) solo sería práctico para los dígitos.

Para solucionarlo, utilizar un par de nibbles mas, para indicar en que columna empieza el efecto, y en que columna acaba, por defecto que esten a un valor no valido, 24 o mayor. En hardware serian 2 comparadores 2 nibbles y un flip flop JK.

Sí, es una buena solución. No se me había ocurrido antes.

En el caso del Mario, y los enemigos, segiriamos teniendo Color Crash, lo unico que haria el SH seria eliminar el color crash del fondo de la pantalla, pero no asi de los personajes.

Correcto. Pero vamos que todos los juegos de spectrum funcionan así. Para evitarlo habría que hacer sprites por hardware, y esto sí que es un cambio significativo en el diseño de la ULA.

En la demo de 128K, cuando escribes, los pixels, aparecen en la derecha de la pantalla (los de la 1º letra)
Para solucionarlo, elimina 8 pixels de la 1º columna, luego pinta el 1º pixel que toque,

FOR x=0 TO 7
- pixel N+x = posicion 8+x, atributo 8+x
NEXT x
En resumen, retrasar 8 pixels, lo que tardaria en pintarle el pixel N, manteniendo los atributos en su lugar en la pantalla
Coste en hardware 1 buffer de 8 bits, 3 bits, para indicar el desplazamiento y 1 bit para indicar si esta activo, 1 comparador de 3 bits, 1 OR o AND, para forzar a segir pintando el BORDER y 1 NOR de 5 entradas (para saber que estamos en la 1º columna y hay que segir pintando el BORDER), asi a groso modo segun el esquema del speccybob.

Sí, ya te digo que la demo la hice de forma rápida, y la publiqué en cuanto se veía algo decente. Habría que hacer lo que dices para que no se viera la basura a la derecha.

Para aprobechar la 1º columna, los 24 bytes, los utilizaria para los atributos que entrasen, desde la izquierda de la pantalla, asi tendriamos los atributos precargados,pudiendo mantener los ciclos del Spectrum real sin mayor problema. En lugar de introducirlos por la derecha.

En realidad da igual por donde lo hagas. Yo lo he hecho así porque resulta más intuitivo pensar en una columna 32 que en una columna -1 (suponiendo que las columnas estándares van de la 0 a la 31).

[Z80user]

El TAP no se como descarglo, lo veo casi como un video, por lo que no veo mas alla de lo que puedo intuir.

De aquí:
http://jbacteria.antoniovillena.es/games/hwscdemo.tap
Y si quieres el código fuente lo tienes aquí:
http://antoniovillena.es/upload/hwscdemo.zip

Le hechare un vistazo, gracias

Para solucionarlo, utilizar un par de nibbles mas, para indicar en que columna empieza el efecto, y en que columna acaba, por defecto que esten a un valor no valido, 24 o mayor. En hardware serian 2 comparadores 2 nibbles y un flip flop JK.

Sí, es una buena solución. No se me había ocurrido antes.

Me he colado un poco, mas que 1 nible, serian 5 bits

Para aprobechar la 1º columna, los 24 bytes, los utilizaria para los atributos que entrasen, desde la izquierda de la pantalla, asi tendriamos los atributos precargados,pudiendo mantener los ciclos del Spectrum real sin mayor problema. En lugar de introducirlos por la derecha.

En realidad da igual por donde lo hagas. Yo lo he hecho así porque resulta más intuitivo pensar en una columna 32 que en una columna -1 (suponiendo que las columnas estándares van de la 0 a la 31).

Yo lo pense mas en plan implementacion real, algunos me dicen de todo, porque para hacer un programa siempre quiero usar ensamblador en lugar de C o demas lenguajes, al hacer un programa en C, pienso en ASM primero, me pasa lo mismo en java, (Para pensar en punteros me viene de perlas, o lo que dicen en java, que NO son punteros).
Si es algo para implementar dentro de la ULA, como es algo que se tiene a mano, es mas facil de aprobechar, en los lenguajes de programacion, nos hemos acostumbrado a utilizar 0 como primera posicion de una matriz, en lugar de 1.
Tambien se podria utilizar la nomenclatura de los ganchillos (los de hacer ganchillo, de merceria vamos) de utilizar los valores desde el 16 al 0 y luego el 00. Lo veo mejor para implementarlo, para el Scroll, seria el valor que suele salir (scroll de derecha a izquierda), al diseñar un juego, seria copiar los atributos de la 1º columna a la ULA, los timmings serian los mismos, ya que no cambiamos cuando leemos los datos, sino cuando los utilizamos realmente.
La diferencia para el programador copiar la 1º columna de atributos al hacer un desplazamiento, para el usuario tener un scroll brusco o suave, asi seria mas a lo que hace la ULA+ un añadido, que mejora el juego si se implementa la funcionalidad, pero que no hace variar el juego en si, pero es algo que el juego tiene que implementar, aunque no debe de ser dificil.

Asi los puristas no pueden decir que es algo que modifica sustancialmente la ULA, es como la ULA+ si esta, se puede aprobechar, si no, ni me preocupo.

Yo cuando creo una rutina, primero pienso en hacerla, luego en optimizarla, luego en hacerla generica (usar la menor cantidad de registros utiles sin utilizar) y luego al integrarla, hago algun cambio de registros si con ello mejoro el rendimiento.
Con esto, he pensado en lo mismo, en como hacer que sea lo menos traumatico para los puristas (mismos timmings para la CPU), y que sea practico, creo que es mejor hacerlo con scroll a izquierdas que a derechas (por ser mas normal), para una rutina de scroll generica a izquierdas, es el ultimo atributo a utilizar, por lo que antes de despreciarlo, se escribe en pantalla. en una rutina multidireccionar hay que conservar el valor siempre, por lo que da igual.

[flopping]

Hola Z80user, ¿tienes los esquemas del speccybob y del speccybob 128?, es que no los encuentro, ya que parece que han borrado todo su rastro, si me pudieras pasar una copia de ellos te lo agradeceria, si tambien hay placas diseñadas y demas, seria perfecto.

Si los esquemas los tengo, Julio hizo un SpeccyBob en 3 placas, por lo que el diseño de las placas, el se que lo tiene hecho, en 3 placas apilables
Si lo quieres, dime tu e-mail y te lo mando (Si alguno mas lo quiere, lo mismo, que me deje un mensaje)

Otra cosa, me quiero grabar las gal del divide, en teoria tengo un programador que lo hace y tambien tengo unas que compre ya programadas, ademas de los ficheros JED de la web del divide, pero no consigo copiarlas o grabarlas correctamente, ya que al hacer la lectura me dice que no son iguales, ¿hay algun problema al grabar los ficheros o leer una y luego grabarla en otra, o es que estoy haciendo algo mal?

Con las GAL/PAL no se demasiado, pero con los PIC cuando lso grababa, la palabra de configuracion la escribia despues de grabarlo, puede que tengan algo, por lo que no se puedan leer despues de escribirse.

Hola otra vez, ¿me podrias pasar esos esquemas del speccybob, del speccybob 128 y placas? en fin si no te importa pasame todo lo que puedas, ya que me interesa mucho el tema del clon del spectrum, muchas gracias

flopping@gmail.com

[Z80user]

http://sblive.narod.ru/ZX-Spectrum/SpeccyBob/SpeccyBob.htm La pagina en donde esta toda la info que conozco del Speccybob, y esta lo que creia que no estaba, los planos de las palcas. en formato PS PostScript o algo asi creo que se llama.
http://www.speccy.org/foro/viewtopic.php?f=8&t=2406 Tu hablanco con julio del Speccybob modificado por Velesoft.
Lo que te podria pasar, es esactamente lo mismo que en las web esa, y lo del 128, pues releete el post ese.
Yo en el papel hize unas modificaciones, para sustituir algunos componentes, cuando tenga tiempo para poder dedicarle, algunas cosas, las queria hacer con una GAL, y hacer lo que velesoft, ampliarlo a la version de 128 KB.
--------------
y para ambos proyectos, speccybob, y clon de la ULA.
para ampliar el esquema a ULA+, seria poner a la salida de los multiplexores de 4:1 una SRAM (estatica), con las lineas de direccion, conectadas a las salidas de los multiplexores y la salida de datos, a la salida de video, las señales CS y RW siempre activas. a falta del circuito de escritura, lo ideal seria una RAM con dole puerto
El problema es que habria que modificar la ROM para que escribiese unos valores en esta RAM, para que veamos los colores, si no, obtendremos una señal negra.
El chip ATF2500, parece un candidato ideal como sustituo, funciona a 5V (El chip ATF2500 creo que lo comento alguien por estos foros), la mayoria de las patillas, salvo 2, son de datos, tenemos 38 a disposicion en formato DIL (facil de soldar para los no muy soldadores), aunque solo las centrales tienen entrada y salida, pero basicamente el esquema del Speccybob, en lo referente a la parte de la ULA (la parte de grafica), deberia de poder implementarse, las ecuaciones para el scroll habria que generarlas y ver si cojen, pero aun sobraban algunos flips flops, la decodificacion de la direccion del border, era simplemente con una patilla, y sin zona de contencion de memoria, aunque no hize todas las formulas, me faltaban, las de los flip flops JK (hay 48 en el chip) cada 4 ecuaciones, consumimos 1 flip flop, asi que los contadores, son 3 sincronos de 4 bits en cascada (como en el Speccybob) con esta limitacion, mas o menos se podia diseñar toada la parte grafica. con unos 8 flip flops, se podria implementar el scroll por hardware.

[Z80user]

Tambien recomendar el clon del Harlequin http://www.zxdesign.info/schematics.shtml basicamente es como un speccybob, optimizado, reduce el numero de puertas logicas e implementa aceso CAS / RAS (rizando el rizo ) es algo mas completo en cuanto a clonado de la ULA real. Mencion aparte del libro, que ya lo puedes obtener con el 100% de fiabilidad, del libro tambien puedes obtener un esquema de como es la ULA, ya que entre el speccybob y como se ve en el libro, la parte de guardar y manejar los bits de border, ink y paper esta implementado de distinta forma, esto era por ajustar los timings de los retardos de los circuitos, para acomodarse a la señal de television, ojo son retardos de dentro del chip con los que juegan, no se puede variar al cambiar un chip por otro, poner una puerta logica mas o menos serian unos 5 ns, lo que es crucial, es el retardo, de todas las lineas, para que el color adecuado salga en el momento adecuado.
Hay mucho purista en cuanto al Spectrum, es uno ordenador con muchos perifericos (billones y billones de combinaciones posibles) pero todos son add-ons, salvo el upgrade del 16K al modelo de 48K y/o cambio de carcasa, en lo demas, todos son primos hermanos, pero parece que hay un movimiento de no hacer otro speccy2000 (ordenador con compatibilidad de spectrum) o al reves Spectrum, con algun extra.
Hace tiempo hable con un usuario de Amstrad, y le pregunte como manejaba la memoria, y era casi identica a como el Spectrum la maneja (en el modo allram introducido por Amstrad, no el creado por investronica para el 128K).
La diferencia del MSX con el Spectravideo, era en donde estan mapeados ciertos puertos.
Del Spectrum, al MSX se diferencian en que el MSX tiene un chip grafico que hace algo, en el Spectrum no hace nada (salvo el flash)
Lo que quiero decir, es que parece que tenemos algo que nos imponemos (tenemos que tener un IBM PC, no vale un clonico), asi que tener "enemigos" al intentar hacer algo nuevo, es algo inherente e ilogico, di que cambias el bit de flash, para que sea el 2º bit de brillo, para que sea el brillo uno de la tinta y otro del papel, obtendras el mismo resultado.

[jzx]

Se me ocurre si se podría, en un 128 que tienen los sincronismos separados y el rgb ttl, coger las señales de video y retrasarlas 0, 1,2 .. hasta 7 pixeles, controlado el número de ciclos de retardo con un registro.
Así se desplazaría toda la pantalla hacia la derecha, y al variar el retardo volvería al centro. Luego, para que no se viera la 1ª y última columnas, se podría generar un "border" que las "tapara", muestreando el color del borde o duplicando el registro $FE.

No sé si funcionaría, ni tengo ahora muchas posibilidades de probar (pero por si alguien lo quiere estudiar ..), pero pienso que se podría hacer el retardo con unos registros de desplazamiento, el problema creo que sería obtener un reloj de pixel para los registros de desplaamiento. Si esto fuera factible, la ventaja sería que no habría que clonar toda la ula, solo sería un añadido y si hay problemas de timming, solo sería en la salida de video, no en el bus.

[mcleod_ideafix]

Se me ocurre si se podría, en un 128 que tienen los sincronismos separados y el rgb ttl, coger las señales de video y retrasarlas 0, 1,2 .. hasta 7 pixeles, controlado el número de ciclos de retardo con un registro.
Así se desplazaría toda la pantalla hacia la derecha, y al variar el retardo volvería al centro. Luego, para que no se viera la 1ª y última columnas, se podría generar un "border" que las "tapara", muestreando el color del borde o duplicando el registro $FE.

Para hacer eso necesitas el reloj de pixel, que en los modelos de 128K lo genera la ULA como señal de 8,8MHz. El problema es que también necesitas saber cuándo se ha terminado de generar el borde y comienza el paper, porque si no, ¿cómo sabes a partir de cuándo se ha de pasar los bits RGB por sendos registros de desplazamiento?

Te haría falta por tanto un contador que se reseteara en cada flanco positivo del sincronismo horizontal y contara píxeles. También te haría falta un comparador de varios bits para saber cuándo comienza el paper y cuándo termina.

También te haría falta un contador de líneas, para saber a partir de qué línea comienza a generarse el paper, y no intentar desplazar una línea que sólamente tenga "border". Este contador se resetearía en cada flanco positivo del sincronismo vertical. Por cierto, la ULA del 128K entrega los sincronismos compuestos, no separados, aunque quizás usando la señal de interrupción es posible discernir cuándo es uno y cuándo es otro.

Tres multiplexores que conmuten de paper "retrasado" a border cuando el contador detecte que es hora de dibujar el borde.

Con todo esto aún hay otro problema: que cuando desplazas el paper a la derecha, es decir, cuando lo retrasas... ¿con qué rellenas los píxeles que quedan en la columna 0? No puedes rellenarlos con lo que había en la columna 31 porque aún no se ha generado. Otro problema es que este esquema sólo podría desplazar la pantalla en un sentido: a la derecha, porque para desplazar a la izquierda habría que pintar píxeles que aún no han sido generados, salvo que uses una memoria que permita guardar una línea entera de pantalla, desplazarla y enviarla a la TV mientras se lee la siguiente línea: es decir, una suerte de doble buffering de una línea de video de capacidad. Esta memoria tendría que ser capaz de guardar dos líneas x 384 píxeles x 3 bits = 2304 bits: una capacidad de memoria que excede con mucho la capacidad de una CPLD estándar (para una FPGA es un rasguñito de nada).

Todo el hardware anterior (contadores de líneas y columnas, multiplexores, registros de desplazamiento, etc) es poco más o menos lo que hay ya en la ULA, así que en mi opinión, para hacer este apaño externo, que no daría el mismo resultado que el scroll hardware que hemos visto de antoniovillena, casi sale igual de caro y de complicado hacer una ULA nueva.

[antoniovillena]

Z80user, si lo vas a implementar físicamente, o sea con circuitos MSI, vas a tener muchos problemas. Y lo peor es que para arreglarlo hay que soldar, desoldar, recablear, etc... Así que casi sería mejor simular el circuito antes o estudiarlo detenidamente sobre papel. Aunque bueno, si lo consigues sería un gran logro.

He estado pensando sobre el tema de tener zonas diferenciadas en la pantalla con y sin scroll. Una solución que no requiere circuitos adicionales sería conmutar el contador del scroll mientras la ULA está pintando la pantalla. El gran inconveniente es que al no ser linear el buffer de video, sólo podemos limitarnos a tercios de la pantalla. Por ejemplo podemos tener nuestra zona de juego con scroll en los dos tercios superiores, y los marcadores/indicadores en el tercio inferior. Otra solución sería dotar a la nueva ULA de un modo de video con buffer lineal, aunque esto haría que no pudieses usar dicho juego en máquinas con ULA antigua (el desorden de líneas haría el juego injugable).

Y para jzx, como te ha respondido McLeod, lo que propones es posible, pero igual o más complejo que un rediseño de la ULA. Y de esta forma no sería posible leer los 24 bytes de atributos adicionales. Para ello necesitas acceder a los buses de direcciones y de datos del Z80, a parte de la salida de video. Y la línea completa que necesitas almacenar en scroll horizontal, se convierten en 8 en el caso vertical (por tanto impracticable en CPLDs).

[antoniovillena]

He estado googleando y he visto que lo ideal para hacer el reemplazo de la ULA sería algo como esto:
http://www.digilentinc.com/Products/Det ... &Prod=CMOD

Sería un CPLD con un regulador de tensión y un conector JTAG que encaja en el socket de la ULA. Con el regulador no hay problema, se usa uno que acepte 5V de entrada. Sin embargo el CPLD más grande que he encontrado con ese encapsulado (VQ44) es el XC9572XL, justo el modelo inferior al que usó Chris (xl95144xl) para su cuasi-clon de la ULA.

También habría que meter resistencias para los 3 DACs de 2 bits que generan las señales Y, U y V, pero no parece que sea muy complicado. Otra ventaja (aparte de que cabe en todos los modelos) de usar una PCB tan pequeña es que los costes por unidad para un lote pequeño son ínfimos.

[mcleod_ideafix]

He estado googleando y he visto que lo ideal para hacer el reemplazo de la ULA sería algo como esto:
http://www.digilentinc.com/Products/Det ... &Prod=CMOD

Las conozco... ese modelo (CoolRunner) no nos vale, por la sencilla razón de que no es tolerante a 5V. Además... quien te dice que las tensiones de 5V y masa están en el mismo sitio que en la ULA... Pues va a ser que no, que no están en el mismo sitio.

El remplazo que se haga de la ULA tendrá que ser por fuerza un diseño "ad hoc". La XC95144XL la tengo en encapsulado QFP de nosecuántas patillas, así que es más ancha que la distancia que hay entre filas de pines. Habría que montar tiras de pines DIP pero de los que hay para SMD, que no atraviesan la placa. De esa forma puedes montar la CPLD en un lado, y las dos tiras de pines en el lado opuesto sin que "choquen". Eso sí, habrá que hacer un montón de vías

[antoniovillena]

Las conozco... ese modelo (CoolRunner) no nos vale, por la sencilla razón de que no es tolerante a 5V. Además... quien te dice que las tensiones de 5V y masa están en el mismo sitio que en la ULA... Pues va a ser que no, que no están en el mismo sitio.

El remplazo que se haga de la ULA tendrá que ser por fuerza un diseño "ad hoc". La XC95144XL la tengo en encapsulado QFP de nosecuántas patillas, así que es más ancha que la distancia que hay entre filas de pines. Habría que montar tiras de pines DIP pero de los que hay para SMD, que no atraviesan la placa. De esa forma puedes montar la CPLD en un lado, y las dos tiras de pines en el lado opuesto sin que "choquen". Eso sí, habrá que hacer un montón de vías

Me refería a que el aspecto sería parecido a éste, pero haciéndolo "ad hoc". Digamos que "mola más" usando ese encapsulado, ya que la placa tendría el tamaño que la ULA original. Pero como en un XC9572XL no cabe, habría que hacerlo como dices (usando un XC95144XL, tiras de pines SMD, placa un poco más grande que la ULA y un montón de vías).

Edito: También sería interesante hacer los agujeros en el lado opuesto al conector JTAG para un conector VGA interno. Aunque no sea posible cargar el firmware VGA y el YUV a la vez (tal vez lo sea con un jumper) y posiblemente sea imposible mantener los timings exactos de la ULA en modo VGA, resulta más práctico ya que cada vez hay menos monitores/TVs que soporten entrada UHF.

[mcleod_ideafix]

Edito: También sería interesante hacer los agujeros en el lado opuesto al conector JTAG para un conector VGA interno. Aunque no sea posible cargar el firmware VGA y el YUV a la vez (tal vez lo sea con un jumper) y posiblemente sea imposible mantener los timings exactos de la ULA en modo VGA, resulta más práctico ya que cada vez hay menos monitores/TVs que soporten entrada UHF.

Bueno, tal y como lo pienso hacer no tendrá salidas UYV, sino RGB, y en la propia placa habrá un pequeño AD722 para generar una señal de video compuesto que se llevará con un cablecito a la entrada del modulador UHF. Esa misma señal estará presente en el bus trasero del Spectrum, como es habitual.

Respecto a VGA: con una CPLD veo varios problemas: uno de ellos es precisamente el timming, que no podría ser el original, puesto que la CPLD no tiene memoria como para un framebuffer que ocupe una línea. Pero lo peor es que a causa de esto, los accesos a memoria dinámica tendrían que ser al doble de la frecuencia (14MHz en lugar de 7MHz) de lo habitual, y eso estaría fuera del alcance de la DRAM incluida en el Spectrum.

Personalmente intentaría ponerle un conector RGB al Spectrum, y usaría un conversor RGB-VGA como los que se usan en proyectos de recreativa para obteener una señal VGA.