Quest escribió:No he leido lo de WOS, pero te puedo decir que cuando estuvimos probando exhaustivamente el modo de 28Mhz, los resultados no fueron buenos. Corrupciones y cuelgues, incompatibilidades con lo existente... Se decició retirarlo. Desconozco si Mcleod hizo alguna mejora posterior que no hubiera publicado o mencionado (no que yo sepa).
El problema de los 28MHz es que es la máxima frecuencia que se genera en el core, a partir del reloj de 50MHz, usando PLLs. Es un problema porque ciertos periféricos, como la flash, necesitan funcionar a una velocidad al menos el doble que la CPU, para poder funcionar correctamente. Hasta ahora, con el tope en 3.5MHz y luego en 7MHz, los periféricos funcionaban a 28MHz (más del doble de lo requerido). Al añadir la frecuencia de 14MHz no hubo problemas, pero al intentar añadir la frecuencia de 28MHz, hubiera sido necesario aumentar la frecuencia de salida del PLL a 56MHz, cosa que se puede hacer, pero me obligaría a cambiar más de una cosa, y como el TEST 21 ya iba cargadito de cambios, no quise añadir uno más, y además delicado.
La otra razón, como comentaba, es que la FPGA tiene un número limitado de bufferes globales (rutas rápidas) por las cuales pueden circular los relojes. Para poder elegir dinámicamente un reloj u otro en el sistema uso unos multiplexores especiales en la FPGA que permiten conmutar de un reloj a otro sin producir glitches, pero esos multiplexores necesitan que tanto sus entradas como sus salidas sean bufferes globales, así que el número de bufferes globales se dispara, hasta que llegaba un momento en que si metía 4 relojes para elegir uno de ellos, me quedaba sin búfferes y el place and route se veía forzado a "fabricar" bufferes de reloj usando lógica de interconexión interna, que es mucho más lenta y más vulnerable a variaciones de skew, lo que supone, en la práctica, un desastre.
La forma correcta de soportar 28MHz es rehacer el módulo cuatro_relojes.v para que genere de partida un reloj de 56MHz, y que dicho reloj sea el que varíe ligeramente para dar soporte a las distintas frecuencias de refresco vertical que soportamos en ZX-UNO. Con un reloj de 56MHz como reloj base, ya se puede hacer que el módulo SPI (y por tanto la flash) vayan a esa frecuencia.
Esto, contando con que el diseño pueda funcionar a 56MHz, cosa que hay que mirar en el reporte de síntesis.
Así que eran tantas las "cositas" que había que solventar que, sinceramente, al sopesar los pros y los contras, decidí ir a lo seguro y estable, y plantarme en 14MHz. 28MHz de CPU no es imposible, pero de momento es una opción que dejo aparcada. Si alguien quiere intentarlo, ya sabe por dónde empezar a tocar
Llegué a poderlo usar, pero un poco a trancas y barrancas. Primero, era con una BIOS que no usaba ningún modo turbo para leer la flash, así que el arranque, aunque tuviera habilitado 28MHz, iba bien. Desde ESXDOS, como siempre, cargaba algún juego (hice la prueba con Manic Miner). Cargaba el cargador BASIC del juego y ponía un STOP antes del RANDOMIZE USR. Dejaba cargar el juego desde DivMMC como siempre hasta el STOP. Entonces es cuando conmutaba a 28MHz y acto seguido, lanzaba el RANDOMIZE USR. El Manic Miner efectivamente va a una leche brutal, pero va.
Otra cosa curiosa de ver es una carga por EAR a 28MHz. No recuerdo si conseguí hacerla andar a esa frecuencia, pero a 14MHz sí que he cargado cosas por EAR (y cualquiera de vosotros puede intentarlo).
Por último, y respondiendo un poco a lo que decía Quest, un modo de 28MHz es útil quizás para incentivar el desarrollo de juegos en Sinclair BASIC, ya que una velocidad 8 veces mayor que el BASIC original, ya te da cancha para hacer juegos en BASIC puro y que sean jugables. Por otra parte, Andrew Owen desarrolló una especificación para un supuesto coprocesador matemático para usar con el Spectrum. Este coprocesador haría las mismas funciones que la RST #28 de la ROM, pero en hardware. Con este copro, el BASIC del Spectrum se aceleraría muchísimo más. Lo malo es que implementar ese copro es muy complejo, sobre todo porque el calculador de la ROM no sólamente maneja números sino también cadenas. Le comenté a Andrew que una opción factible para obtener algo parecido a un rendimiento de copro en el BASIC del Spectrum podríá ser elevar la velocidad de la CPU al máximo cuando entrase en la RST #28, para volverla a dejar como estaba al salir de ella. En ese sentido, cuanto más velocidad consigas implementar, mejor. A Andrew le gustó la idea y la podría implementar en una siguiente revisión del Open SE.