Noticias sobre la placa superfo harlequin

[LeoCZ]

En la revista Elektor nº60 explica el funcionamiento del teclado del Spectrum + y sale un circuito para armar mediante pulsadores, eso si, usa llaves electrónicas para las teclas extras del plus, si bien puede parecer medio engorroso, no se ve tan complejo.
Esta es la revista Elektor donde sale el circuito:
http://www.speccy.org/trastero/cosas/el ... o85%29.pdf

[mcleod_ideafix]

Bueno ya nos contaras esos proyectos conforme se vayan haciendo realidad, que yo tambien le tengo unas ganas a mis placas que no veas

A colación de los proyectos e incluso de lo que hemos estado hablando sobre el video en el Spectrum...

Resulta que me he entretenido en pasar el esquemático del Harlequin Superfo (la parte que sería digamos, la ULA) a una descripción en Verilog. Con la descripción hecha ya puedo ver cronogramas en pantalla como si tuviera la placa montada.

Para probar esta "ULA" le he puesto una "memoria" que siempre entrega el mismo dato: 10101010b , y he precargado en el registro que guarda el valor del borde, el valor 7.

Con eso puedo "ver" qué pasa por la pantalla en cada momento: si es "border" la ULA sacará el valor 7 por la salida RGB, si es paper, sacará el valor 101b (5), y si es "ink" (pixel encendido) sacará el valor 010b (2).

Dado que la memoria saca el mismo valor para la parte de píxeles como para la parte de atributos, el efecto que se vería en pantalla, si esta ULA estuviera conectada a una tele, es una trama de rayas verticales desde arriba hasta abajo, alternando rojo y celeste, con el borde blanco, y con el flash activado. Algo así (aquí el flash no se percibe):


El cronograma obtenido es el siguiente (si no se ve completo, botón derecho al gráfico y elegir "Ver imagen"):


Cubre una línea de video completa. Hay dos marcas que enmarcan este cronograma, desde el inicio de un pulso horizontal, hasta el inicio del siguiente pulso horizontal. La distancia, 63,9999us (64us es la duración nominal de una línea)

La línea marcada como RGB muestra el color que se vería en cada punto de la pantalla dentro de esa línea. Durante los periodos de blanking, es decir, cuando el rayo no está pintando la pantalla y está "volviendo" de derecha a izquierda, se ve que el valor de RGB es 0. Cuando está pintando el borde izquierdo o derecho, es 7. En medio de esos dos bloques que son los bordes izquierdo y derecho hay una zona "borrosa" donde no se percibe qué color es el que se está viendo. Basta hacer un poco de zoom, por ejemplo, a los primeros píxeles pegados al borde izquierdo para ver mejor qué pasa ahí...



CLK7 es el reloj de pixel. A cada período de esta señal, se pinta un nuevo pixel, sea de paper, ink, border, o "nada".

HC es un contador de píxeles. Cuenta desde 0 hasta 447 inclusive. Las primeras 256 cuentas son los píxeles que van en el área de pantalla correspondiente al "paper". La figura muestra precisamente los primeros 15 o 20 píxeles de esta zona.

VA es la dirección de memoria que la ULA está leyendo en este momento. Para la ULA, la memoria no va desde 16384 en adelante, sino desde 0 en adelante. Así, la dirección 256 que aparece, es en realidad la dirección 16640 de la CPU. Lo que estamos viendo pues es la generación de la segunda línea de la pantalla. Tras el 256 hay un 6144 que se corresponde con la dirección 22528, es decir, donde se almacena el atributo para este scan. Justo después se leen los 8 siguientes píxeles (dirección 257) y el atributo que le corresponde a esos píxeles (dirección 6145). Las zonas en azul marcadas como Z son espacios de tiempo en los que la ULA no accede a la memoria de video.

Quien determina que lo que se lee de memoria es bitmap o atributo son las señales AL1 y AL2. Por otra parte, la señal OutLatch indica cuando se empieza a enviar a pantalla la siguiente trama de 8 píxeles.

El "pistoletazo de salida" para dejar de generar el borde y comenzar a generar el "paper" lo da la señal Vout. Cuando pasa a nivel bajo (coincidiendo con OutLatch) vemos que la señal RGB deja de enviar el 7 (color de borde) para empezar a enviar píxeles en rojo (2) y celeste (5). Esa secuencia de 2 y 5 es lo que se veía borroso en la imagen anterior.

Una de las cosas que me está permitiendo ver este cronograma es que hay diferencias respecto a la ULA de Sinclair. De momento veo que el borde izquierdo, que debería durar hasta el pixel 15 inclusive, aquí llega hasta la mitad del pixel 10. Esto hace que el borde izquierdo en lugar de tener 48 píxeles de grosor tenga 43 píxeles, y por tanto el borde derecho tenga unos 53 píxeles en lugar de 48. No es algo molesto, pero me p regunto si afectará al mecanismo de contención y a los T-states que se supone que deben ocurrir desde una interrupción hasta el comienzo del proceso de lectura de memoria.

Para ello, podemos sacar otro cronograma que muestre el tiempo desde que ocurre una interrupción hasta que comienza a leerse la VRAM...

Medimos desde que ocurre el flanco de bajada de la interrupción del retrazo vertical...


Hasta que ocurre la primera contención en el acceso a memoria, indicada porque la señal ContEn pasa a nivel bajo:


La diferencia entre los tiempos medidos es de 4096.03866 microsegundos. Medido en ciclos de reloj de pixel, suponen 4096.03866 x 7 = 28672.27062 ciclos de reloj de pixel. Un ciclo de reloj de la CPU cubre dos ciclos de reloj de pixel, así que dividimos entre 2 para obtener finalmente 14336.13531 ciclos (en realidad esto deben ser ciclos "enteros", no valen decimales, así que el resultado real es 14336). Esto coincide con la información que se muestra en esta página:
http://scratchpad.wikia.com/wiki/Contended_memory

La misma página indica que cuando ocurre un acceso en este ciclo 14336, el mismo es retrasado 6 ciclos (de CPU) de reloj.

Como podemos ver en esta sección del cronograma...


La duración de la señal de contención (ContEn = 0) es de 1714.272ns, lo que equivalen a 12 ciclos de reloj de pixel. Y esto significa la mitad de ciclos de CPU, es decir, 6 ciclos de espera (como máximo). También coincide

Por otra parte, el tiempo en que no hay contención (ContEn = 1) es de 4 ciclos de pixel, es decir, 2 ciclos de CPU (quizás no se vea en el cronograma y tengais que darle como dije al principio para verlo aparte). Esto también coincide con lo que dice el documento, en el que habla de 2 ciclos en los que no hay contención.

Con estas medidas, y a falta de hacer algunas un poco más sofisticadas, creo que tengo una descripción bastante fidedigna de esta ULA.

Gracias a estos cronogramas he podido ver que hay algunas inconsistencias "menores" tales como que la anchura del primer píxel y del último pixel son diferentes que el resto de píxeles. No sé si es que yo me he equivocado al escribir la descripción en Verilog, o si realmente es así. En mi caso lo he resuelto desplazando medio ciclo de reloj la señal Vout a la izquierda, lo que he conseguido intercalando un inversor en la entrada de reloj del biestable U19B para que éste se dispare con el flanco negativo en lugar del positivo.

Antes, con la descripción supuestamente igual a la del esquema, obtenía este comportamiento en el primer pixel (el que vale 2 después de la secuencia de píxeles con valor 7):


Se ve que es la mitad de ancho que los que le siguen. Analogamente, el último pixel es una vez y media más ancho que los que le preceden:


Hasta que no tenga el circuito real no podré saber con seguridad si esto es error mío, o está así en el circuito. En caso de que estuviera así en el circuito, creo que puede arreglarse implementando el inversor que necesitamos con alguna de las puertas sobrantes de U30 (4 puertas XOR de las que sólo usamos 1 ó 2)

[curioso1100]

Resulta que me he entretenido en pasar el esquemático del Harlequin Superfo (la parte que sería digamos, la ULA) a una descripción en Verilog ...

Es una pena que no use sombrero, porque después de tu explicación sería el momento de quitármelo. Sólo se me ocurre una palabra: GENIAL

Muchas gracias por compartir con todos tus experimentos.

Un saludo.

[flopping]

Y yo me pregunto, despues de esta abrumadora avalancha de datos, cronogramas y explicaciones, ¿que sacamos en claro de todo esto?, ya que por lo que comentas, solo se modifican un par de pixels y no creo que visualmente se note, vamos que creo entender que todo esto es simplemente para verificar que los circuitos equivalentes a la zona de video de la ULA del clon, no se comportan igual que una ULA real, ¿es eso o hay algo mas?, de todas formas dentro de poco podras experimentar en un clon real, ya que ya me han indicado que me mandas las placas del clon, asi que en unos dias ya las tendremos disponibles, asi podremos comprobar cuanto de "exacto" es el clon con respecto a un spectrum real, aunque ya te digo yo que hay "diferencias", quiza algunas mas notables que otras, recuerda que se movieron buses para poder aislar el bus compartido con el teclado, por medio de resistencias, ademas de las resistencias que faltaban en varias señales como tu mismo descubriste, pero bueno, para eso estan las pruebas que le haremos al clon, para poder descubrir esas "diferencias" y corregirlas en la medida de lo posible y seguro que vas a "disfrutar" con ello como un "enano", jajajajajaja....

Pues nada ya os contare cuando tenga las placas, que ya falta muy poco, salu2.

[mcleod_ideafix]

Y yo me pregunto, despues de esta abrumadora avalancha de datos, cronogramas y explicaciones, ¿que sacamos en claro de todo esto?

Que me encanta poder "ver" cómo funciona el circuito aunque aún no lo tenga delante. Y como puedo hacerlo, pues lo hago usar el ISim es mucho más cómodo que poner tropecientas sondas de un analizador lógico en un circuito real. Comprendo a Chris Smith cuando en el blog contaba cómo estaba midiendo timmings, señales, etc, y comparaba con la información que existía en la época sobre la forma de funcionar de la ULA. Esto que he contado es un pequeño ejercicio en este mismo sentido.

También saco en claro que el error era mío. He corregido la descripción y ahora sí que veo que se comporta "como debe comportarse". No, no hay que tocar nada en la placa. El clon que tendremos generará unos timmings 100% fieles a la ULA original (del Spectrum 48K). Eso sí: el borde izquierdo seguirá siendo un poco más flaco que el borde derecho. Ahí no coincide con la ULA "real". De todas formas no se notará.

La otra cosa que saco en claro de este experimento es que tengo el espacio justo en la CPLD para meter más cosillas a esta ULA Para poder probar esas... cosillas.... no tengo más que añadir código a la descripción y ver cómo se comporta con la ULA funcionando. Una vez que el código está verificado, puedo "fabricar" el chip (por decirlo de alguna forma). Creo que ya sé cómo voy a usar una de las placas que me lleguen...

Otra cosa más que consigo con esto es tener una representación fiel de cómo debe comportarse todas y cada una de las partes del circuito. Así, en caso de avería, no tengo más que comprobar los cronogramas del circuito "averiado" y compararlos con el circuito "bueno" y dar con el chip estropeado lo antes posible.

Tan fiel es que puedo perfectamente incorporar a este diseño un Z80, su memoria ROM y RAM, y tener un Spectrum funcional que pueda ver en acción no sólamente instrucción a instrucción, sino ciclo de reloj a ciclo de reloj (de video). Esto viene estupendo para ajustar al microsegundo rutinas de sprites y cosas así, porque ahora puedo ver dónde puedo tener contienda, cuánto dura, y como evitarla en la medida de lo posible. Por ejemplo, una de las cosas que se observan ahora con más facilidad es que cuando se usan las interrupciones para animar sprites sin parpadeo, realmente estamos perdiendo un tiempo precioso porque la interrupción ocurre en medio de un vasto intervalo temporal en el que la ULA no accede a video. Si hubiera alguna forma de ajustar el código que se ejecuta para que la generación y pintado de sprites ocurriera al principio de este intervalo, y no a la mitad, tendríamos practicamente el doble de tiempo para pintar dichos sprites.

Unos ejemplos (y de paso, más cronogramaaaaas)

Cuando se usa la interrupción para sincronizar movimiento (sprites, scroll, lo que sea) con el barrido de pantalla, se usa la cifra estándar de 14336 (ciclo +/- según ULA) como número de ciclos máximo que puedes "gastar" desde el momento en que ocurre la interrupción hasta que la ULA comienza a leer la memoria para pintar la pantalla. Es decir, el tiempo que hay entre estos dos marcadores:


Pero si te fijas, antes de que ocurra esa interrupción, hay un montón de tiempo antes de eso en donde la ULA tampoco accede a memoria. Si sincronizamos el código para que en ese momento sea cuando se dedique a pintar sprites, en lugar de 14336 ciclos tenemos unos 26977 ciclos, que es lo que hay entre estos otros dos marcadores:


Analogamente, si se quieren hacer efectos con el borde, ahora me es más sencillo porque puedo controlar cuánto tiempo tengo desde que comienza a pintarse el borde derecho hasta que el rayo vuelve a la izquierda y termina de pintar el borde izquierdo. Es el tiempo que hay entre estos dos marcadores (98 ciclos de reloj):


Incluso, por poner un ejemplo más "extremo", puedo ahora escribir código que "persiga" al rayo catódico, haciendo que todas las escrituras en memoria ocurran justo después de que el rayo pase por la zona que acabo de pintar. Así tendría incluso más tiempo para dibujar sprites y ni aún así parpadearían. Se puede combinar esto con la técnica de los sprites combinados y hacer que el código que genera el compilador de sprites se ejecute de forma que la actualización en pantalla haga esta "persecución". Si no pudiera ver estos cronogramas, tendría que ir tanteando por ensayo y error. Hay emuladores como el Spectaculator y el ZXSpin que me muestran en la ventana de depuración los T-States que han ocurrido desde la última interrupción, pero ninguno de ellos me dice (o si tienen esa opción no sé dónde está) qué está haciendo la ULA en el momento en que estoy ejecutando la instrucción actual. Aquí sí que lo veo

[Scooter]

¡Que poco que se de electrónica!
Cada día menos...

[flopping]

No es que sepas poco, es que el tema es "complejo" y visto asi sin el esquematico delante, puede parecer aun mas "liante".

Bueno pues parece que Mcleod tambien comete "errores", jejeje...menos mal que te has dado cuenta, ya pensaba que ibamos a tener que modificar la placa, aunque quiza no por esto, pero igual "algo"sale cuando tengamos el clon real.

Igual que has implementado la señal de video, supongo que tambien puedes implementar la memoria y ver los accesos, lecturas, etc..bueno quien dice memoria dice, practicamente cualquier cosa del spectrum, aunque habra cosas que controle directamente la CPU y no la ULA, por eso cuando dices lo de poner un Z80 y demas, ¿es "meterlo" fisicamente o describirlo en el lenguaje del ISim que utilizas? ya que de esa forma te puedes construir un ordenador "virtual" y tenerlo todo "cronografiado", lo cual es perfecto como bien dices para reparar.

Pues nada Mcleod, sigue "divirtiendote" que ya vemos que estas disfrutando "mogollon", ah una cosa mas, cuando dices lo de meter "cosillas" a esa ULA, te refieres a lo de añadirle mas funcionalidades al clon ¿no?, ¿o es hacer una ULA completa en esa CPLD?, pues nada sigue asi y a disfrutar que esto ya se ve que te "encanta", (ojala en mi epoca de estudiante hubiera existido el ISim, la de trabajo que me habria ahorrado, jajajaja), salu2

[mcleod_ideafix]

Igual que has implementado la señal de video, supongo que tambien puedes implementar la memoria y ver los accesos, lecturas, etc..bueno quien dice memoria dice, practicamente cualquier cosa del spectrum, aunque habra cosas que controle directamente la CPU y no la ULA, por eso cuando dices lo de poner un Z80 y demas, ¿es "meterlo" fisicamente o describirlo en el lenguaje del ISim que utilizas? ya que de esa forma te puedes construir un ordenador "virtual" y tenerlo todo "cronografiado", lo cual es perfecto como bien dices para reparar.

Exacto. Es coger una descripción en Verilog (así se llama el lenguaje) e integralo junto con la descripción de esta ULA, memoria, etc, y sí, tendría un Spectrum completo del cual podría mirar cualquier señal que genere, comodamente y con mucha flexibilidad.

ah una cosa mas, cuando dices lo de meter "cosillas" a esa ULA, te refieres a lo de añadirle mas funcionalidades al clon ¿no?, ¿o es hacer una ULA completa en esa CPLD?

Ambas cosas: a partir de aquí puedo probar modificaciones sin soldar ni un solo cable, y sólo una vez que veo que funcionan dichas modificaciones, aplicarlas al clon real. O bien puedo coger el clon, quitarle un montón de chips de la parte de la ULA, y sustituirlo por una pequeña CPLD que remede toda esa funcionalidad (y la que añada).

El ISim es un componente del ISE WebPack, que es el entorno de trabajo de Xilinx para CPLD y FPGA. Puedes descargártelo gratis de la web de Xilinx. Para hacer lo que yo he hecho no necesitas ninguna FPGA ni nada. Todo se ejecuta en tu propio ordenador. Sólamente necesitas acceso a una placa con FPGA o CPLD si pretendes "volcar" el diseño a uno de estos dispositivos.

[Z80user]

Yo aprendi VHDL, es el otro lenguaje que hay, para hacer diseños de este tipo (al menos los 2 mas conocidos), en las GAL/PAL tambien he visto que lo hacen apartir de ecuaciones. que visto lo visto con las GALs del DivIDE, casi que prefiero programar los 1 y 0 del fichero

Yo tambien hare un diseño en VHDL cuando me llege la placa, porque le quiero aprobechar los 16 KB de RAM que no se aprobecharan, para habilitar la 2º pantalla, como en los 128 KB.
Y para esto necesitare fijo algo mas de chips de los que tomar alguna puerta logica sobrante.

mcleod_ideafix Ya que te pones, poner un contador de tiempos que se pueda leer y resetear desde software, para contar el numero de T-States en que la ULA ha pausado el Z80, tampoco seria mala idea.

¿ En que CPLD entra la ULA ? y ¿ cuanto sobra ?.
y una duda que tengo, la pantalla esa que has generado, ¿ como la has obtenido para poder verla?, La que esta despues del texto "aquí el flash no se percibe"

[flopping]

Veo que el clon ha generado muchas expectativas, eso es bueno, muy bueno, ya que a partir de el, se pueden hacer mejoras y modificaciones muy facilmente, ya contareis a ver que "descubris" cuando lo tengamos en nuestro poder, pero por lo que veo esto "promete".

Al final tendre que aprender Verilog o VHDL, ya que veo que son bastante potentes para este tipo de asuntos, ¿alguna pagina desde donde me los pueda descargar y tenga algo mas de info?, muchas gracias y seguir asi, salu2.

[mcleod_ideafix]

mcleod_ideafix Ya que te pones, poner un contador de tiempos que se pueda leer y resetear desde software, para contar el numero de T-States en que la ULA ha pausado el Z80, tampoco seria mala idea.

¿Y cómo lo usarías desde un programa?

¿ En que CPLD entra la ULA ? y ¿ cuanto sobra ?.

y una duda que tengo, la pantalla esa que has generado, ¿ como la has obtenido para poder verla?, La que esta despues del texto "aquí el flash no se percibe"

Es una captura de pantalla de Spectaculator después de haber ejecutado un programa tal que así:

Código: Seleccionar todo

10 BORDER 7: FOR n=16384 TO 23295: POKE n,170: NEXT n: PAUSE 0

[mcleod_ideafix]

Al final tendre que aprender Verilog o VHDL, ya que veo que son bastante potentes para este tipo de asuntos, ¿alguna pagina desde donde me los pueda descargar y tenga algo mas de info?, muchas gracias y seguir asi, salu2.

Al final te pasarás al lado oscuro... como hice con Jepalza...
El ISE Webpack, que es lo que yo uso, está en la página de Xilinx:
http://www.xilinx.com/support/download/index.htm

[flopping]

JEJEJE...lo que pasa es que soy algo corto de vista e igual en el lado oscuro no veo muy bien, supongo que habran linternas en el lado oscuro ¿no?, JAJAJAJAJAJA....

Si yo nunca me he negado a utilizar chips programables, lo que ocurre es que me gusta la electronica a la "vieja usanza", ya que si ves un circuito puedes sacar su esquematico, ver que hace y comprenderlo, un chip programado, si no tienes su "codigo", poco puedes ver o hacer, para muestra un boton, la "famosa" ULA de nuestros spectrums, vale, no es un chip programable, pero para el caso, llamemoslos "custons chips", hasta que alguien no se ha metido con analizadores, investigando documentos, decapando chips y pasarlos por microscopios, etc..no hemos podido tener un circuito "equivalente" y total solo han pasado ¿cuanto 25, 28 años?, como veras si no tienes la "descripcion" interna, un chip programable es mucho mas dificil de "entender" que los chips logicos TTL o CMOS, hasta leer una pal o gal protegida es todo un mundo.

Pero como ya he dicho en repetidas ocasiones, el trabajar con chips programables es lo mas comodo, rapido y seguro que existe, puede incluso que mas barato, eso jamas lo pondre en duda, lo que ocurre es que la programacion no es mi "fuerte", pero considero que son una "ayuda" muy importante sobre todo para el desarrollo, como bien dices, no has soldado nada y mientras no lo metas en un chip fisico, solo es trabajo "intelectual".

De todas formas, a los que desarrolleis mejoras en el clon de spectrum, me gustaria que ademas de la opcion de meter chips programables, se pudiera implementar tambien con electronica convencional, ya que si ahora mismo lo estais haciendo a la inversa, supongo que tambien se podra revertir el proceso y desarrollarlo a posteriori en circuiteria convencional.

No creo que sea el unico que piensa asi y seria buena cosa el tener las dos vertientes para elegir la que mas se ajusta a nuestras necesidades, ¿no creeis?, ademas no son incompatibles entre si, ni mucho menos.

Gracias por vuestros aportes y esperamos en breve ver muchos mas, gracias Mcleod por el enlace, voy a ver si me tienta el lado oscuro o me quedo en la "luz", jajajajaja, salu2.

[mcleod_ideafix]

De todas formas, a los que desarrolleis mejoras en el clon de spectrum, me gustaria que ademas de la opcion de meter chips programables, se pudiera implementar tambien con electronica convencional, ya que si ahora mismo lo estais haciendo a la inversa, supongo que tambien se podra revertir el proceso y desarrollarlo a posteriori en circuiteria convencional.

Sí, pero a lo mejor resulta que para hacerlo con TTL discreto necestas un montón de ellos. La verdad, no seré yo quien haga esa conversión. Si uso CPLD's es precisamente para no preocuparme de buscar TTL equivalentes, ni montar circuitos más grandes que el propio Spectrum. Los TTL's están bien cuando empiezas, pero no son prácticos. Una CPLD, de hecho, te da más flexibilidad y comodidad no sólamente para diseñar, sino también para buscar fallos, aprender cómo funcionan los circuitos lógicos, etc.

Además, partiendo de la descripción en Verilog puedes sacar el esquemático equivalente. El propio ISE te saca algo así como el "esquema tecnologíco" de la descripción, pero es mareantemente complicado.

Hace ya bastantes años, cuando alguien necesitaba diseñar una pequeña ROM para arrancar alguno de los nuevos microprocesadores de la época (6502, Z80, 6800, etc), recurría a soldar diodos en determinados sitios para formar unos y ceros. Era muy fácil "ver" el contenido de esa ROM porque la secuencia de diodos y no-diodos te daba el contenido de la misma en binario. Cuando se popularizaron las EPROM's de ventana, con sus correspondientes grabadores y borradores, ¿piensas que la gente fue reacia a usarlas porque "con estos chips no puedes ver el contenido si no es con un aparato especial" ?

Ya lo he contado un montón de veces: estoy convencido de que el futuro de nuestros micros pasa porque cada uno de ellos tenga una descripción fidedigna en alguno de los lenguajes HDL más comunes. Con eso tienes preservada la máquina. Un esquemático aún tiene ambigüedades, por ejemplo porque cierta parte del circuito dependa de que tal o cual puerta lógica sean de la familia HCT o LS o la que sea (esto lo sufrí en mis carnes con el clon del Jupiter Ace). En una descripción hardware, esas dependencias desaparecen, lo que signfiica que el circuito podrá funcionar en cualquier dispositivo presente o futuro, aunque la tecnología (y los voltajes) cambien.

Describir hardware es un poco un "arte oscuro", por eso decía lo de "venirse al lado oscuro". Ahora, donde estás, hay luz, pero es la luz de una cerilla. En un pantallazo de ISim obtengo mucha más información del circuito que la que cualquier ingeniero pueda obtener del clon "real" usando un analizador lógico. Eso sí que es trabajar con luz

[flopping]

Si ya se que eres reacio a pasar las descripciones de verilog a TTL, yo intentare hacer lo que pueda, pero necesitare ayuda, ya que estoy bastante pez en el tema.

Yo no digo que desterremos los chips programables, para nada, solo digo que seria bueno tener las dos tecnologias para elegir la que mas nos convenga, si hablamos de tecnologia, ¿que coño hacemos unos tios de mas de 40, con "juguetitos" de hace mas de 30?¿no seria mejor dedicarnos a los PC y sus ultimas tecnologias a tropecientos mil Mhz?, entonces ¿por que lo hacemos?, pues por nostalgia, añoranza, por que nos gusta lo retro basicamente, ¿no te parece incongruente hacer un micro antiguo con un solo chip?, ojo que no me tachen de purista, estoy diciendo que seria bueno tener las dos opciones, no me niego a ninguna de las dos, no como otros, pero si que digo que si hablamos de retro, ¿por que no utilizar retro?, otra cosa es que queramos usar un USB o memorias flash, tecnologia que no existia en la epoca y que por tanto es logico que se adapte con tecnologia nueva, ¿pero que tiene de retro meter un ordenador en un chip?.

Me parece estupendo lo de preservar las maquinas con la descripcion en verilog, como bien dices es portable y demas, todo esto ya lo hemos hablado mas de una vez, asi que no creo que cambiemos nuestras propias "ideas" de lo que es retro, y me parece bien, si todo el mundo pensara igual, que aburrido seria el mundo.

Pues nada mas, lo dicho, a mi me interesa cualquier "avance" sobre el tema y si se hace de varias formas, pues mas opciones para elegir, que es mas complicado, pues si, que hacen falta mas chips, pues tambien, que es mas voluminoso, eso es evidente, y asi podriamos poner miles de pegas, pero cada uno cree en lo que quiere, si te fijas hoy dia aun se siguen vendiendo amplificadores de valvulas y los "entendidos" los buscan como "locos", ¿por que, si con la tecnologia de hoy dia todo es mas pequeño, mas bonito y mejor?, pues chico, algo tendran cuando son tan apreciados, ¿no crees?, salu2.