ZX-Uno

Efectivamente, sólo deja de funcionar en el core principal (el resto no lo sé porque no me deja cambiar), si dejo el core PCXT por defecto, cuando hago reset, en la pantalla de presentación no responde a las teclas de entrada a bios o cambio de core, pero en cuanto vuelve a cargar el core de PC las teclas vuelven a funcionar.

ManuFerHi escribió:Efectivamente, sólo deja de funcionar en el core principal (el resto no lo sé porque no me deja cambiar), si dejo el core PCXT por defecto, cuando hago reset, en la pantalla de presentación no responde a las teclas de entrada a bios o cambio de core, pero en cuanto vuelve a cargar el core de PC las teclas vuelven a funcionar.

Sospecha de distwave confirmada pues. El teclado se queda en un estado que requiere recibir un reset. Otra prueba, si en lugar de apagar y encender el ZXUno, desenchufas y enchufas el teclado, vuelve a funcionar también sin necesidad de pasar de nuevo por XT?

spark2k06 escribió:

ManuFerHi escribió:Efectivamente, sólo deja de funcionar en el core principal (el resto no lo sé porque no me deja cambiar), si dejo el core PCXT por defecto, cuando hago reset, en la pantalla de presentación no responde a las teclas de entrada a bios o cambio de core, pero en cuanto vuelve a cargar el core de PC las teclas vuelven a funcionar.

Sospecha de distwave confirmada pues. El teclado se queda en un estado que requiere recibir un reset. Otra prueba, si en lugar de apagar y encender el ZXUno, desenchufas y enchufas el teclado, vuelve a funcionar también sin necesidad de pasar de nuevo por XT?

No eso ya lo había probado y sigue igual, requiere desconexión de alimentación total para volver a su estado normal.

DistWave escribió: Qué raro, no se hasta qué punto se puede considerar que sea un bug del core si se produce una vez reiniciado
Supongo que tendrá que ver con la implementación del controlador de teclado 8042 (en este core la comunicación es bidireccional) que deja al teclado en un modo de trabajo que requiere un comando de reinicio, como ocurre en los PCs. Pero este comando debería ser enviado desde el core que arranca el ZX-UNO, es imposible reiniciar el teclado desde el core XT al reiniciar la FPGA.

Anda, yo había notado eso mismo, pero no se me había ocurrido por qué pasaba. Supongo que sería una cosa que debería llevar la BIOS, o incluso la boot ROM.

Esta en una pregunta para DistWave.

He probado este core en un ZX-Uno con 512 KB, y he comprobado, como bien decías, que en el modo MCGA no se dibujan las últimas líneas de la pantalla porque faltan 2,5 KB de memoria de vídeo.

Si los modos gráficos soportados son: MCGA/VGA 320x200x256 13h y EGA 320x200x16 12h, y 80x25 en modo texto ¿se podría hacer 2 cores, uno con soporte solo EGA y otro con soporte solo MCGA/VGA, y que al quitarle a este último el soporte EGA con los recursos liberados poder "crear" los 2,5 KB de memoria que faltan para poder presentar las últimas líneas de pantalla en el modo MCGA/VGA?

Pregunto desde mi profunda ignorancia.

desUBIKado escribió:Esta en una pregunta para DistWave.
¿se podría hacer 2 cores, uno con soporte solo EGA y otro con soporte solo MCGA/VGA, y que al quitarle a este último el soporte EGA con los recursos liberados poder "crear" los 2,5 KB de memoria que faltan para poder presentar las últimas líneas de pantalla en el modo vga?.

No soy distwave pero me la se: no se puede, lo que falta es RAM interna de la FPGA para simular RAM de vídeo. La RAM de vídeo la usan esos modos cuando se activan, pero no hay una RAM de vídeo por modo, se usa la misma. En definitiva quitar otros modos o incluso otras cosas que no sean modos gráficos no va a conseguirnos más RAM de vídeo.

Supongo que "crear" RAM en la FPGA es posible, al fin y al cabo es un circuito, pero probablemente requiera muchísimo espacio en la FPGA y además es posible que su rendimiento sea bastante peor, por lo que aún si fuera posible no sería recomendable. Este último párrafo empieza por un "supongo", téngase en cuenta

Si seré torpedo , ya he visto que a esta misma cuestión ya respondieron McLeod y DistWave:

viewtopic.php?f=56&t=815&p=12309&hilit= ... pga#p12309

Nunca 2,5 KB's dieron tanto mal

And what about to use internal SRAM as video RAM and maybe ROM and external SRAM as computer RAM?Is it too complicated?

Mientras hacía la modificación de este core para la pantalla TFT me he dado cuenta que en la versión de 2 megas internos están definidos los pines del puerto de expansión y se les pone valor constante. Esto es peligroso, por ejemplo, si alguien tiene enchufado un addon en un ZX-Uno con 2 MB internos, y pone el core de pc. Si es el addon HDMI/WiFi, éste recibiría un "0" en el pin de TX de la UART, y eso es potencialmente dañino para la fpga y el addon.

Por lo que habría que corregirlo, dejar esos pines sin usar y el módulo verilog principal quitárselos de la definición.

Así es. En mi caso particular decidí separar los proyectos ISE para cada versión de memoria al fijarme en eso. Aunque es más "dificil" de mantener todas las versiones, como iba a centrarme más bien solo en 1 (la de 2mb int), me hice el UCF sólo con los pines estrictamente necesarios para esa versión, y consecuentemente, el top module también solo con los estrictamente necesarios. Además de evitar el peligro, también te evitas un montón de warnings innecesarios.

No se cómo le parecerá mejor a Distwave para organizarlo...