Re: Core PC/XT BETA
Publicado: 29 Dic 2016, 12:42
Lastima que ZEsarUX no compile para DOS, sino se podría meter un emulador de ZX-Uno en el ZX-Uno.Hark0 escribió:Que alguien cargue algún emulador de Spectrum por dios.... XD
Lastima que ZEsarUX no compile para DOS, sino se podría meter un emulador de ZX-Uno en el ZX-Uno.Hark0 escribió:Que alguien cargue algún emulador de Spectrum por dios.... XD
Si puede correr DOS, quizá pueda Linux... Y a partir de ahí el ZXUno dentro del ZXUno xDUto escribió:Lastima que ZEsarUX no compile para DOS, sino se podría meter un emulador de ZX-Uno en el ZX-Uno.Hark0 escribió:Que alguien cargue algún emulador de Spectrum por dios.... XD
Es algo que he notado con el volumen alto, pero tampoco me ha parecido excesivo. Además, cualquier PC emite esos ruidos por el Speaker si lo conectas por ejemplo a la entrada de una Sound Blaster... así que aunque sea molesto, forma parte del sistema originalQuest escribió:Las cosas que funcionan van bastante bien, la verdad. La salida de audio tiene algo de ruido... no se muy bien a qué puede ser debido... ocurre también al leer de la SD, etc.
El tema de la memoria es bastante complicado, de hecho es sin duda lo que más tiempo me ha llevado modelar hasta llegar al estado actual: utilizar la SRAM para la memoria RAM y la BRAM para la memoria de vídeo.Quest escribió:Las incompatibilidades que veo, principalmente parecen ser por la implementación incompleta de los modos gráficos. Lástima que dispongamos sólo de 512K de SRAM. Quizá cambiándola por la de 2Mb...
Habría que implementar el modo CGA, sus paletas, etc tanto en el hardware como en la BIOS. El mayor problema es que tenemos la FPGA a tope, pero seguramente se podría eliminar algo de lógica (por ejemplo el modo 640x480x16 está implementado, pero como puedes ver en el Visual Player no hay memoria de video suficiente para que sea usable)Quest escribió:Por cierto, una preguntilla... no hay modo posible de meter los modos CGA? Al menos para poder correr gran parte del soft español... y bueno, windows 3.0 aunque sea en modo CGA (aun teniendo modo CGA, haría falta parchear algo? en mi HP200LX con 80186 va directamente)
Como se os va la pinzaspark2k06 escribió:Si puede correr DOS, quizá pueda Linux... Y a partir de ahí el ZXUno dentro del ZXUno xDUto escribió:Lastima que ZEsarUX no compile para DOS, sino se podría meter un emulador de ZX-Uno en el ZX-Uno.Hark0 escribió:Que alguien cargue algún emulador de Spectrum por dios.... XD
Entiendo... pues también podría haber otra opción... tener varias versiones del core, dependiendo de qué modos gráficos queramos usar. Uno para CGA (o CGA + EGA), otro para MCGA, etc (no se los que se podrían tener, sólo es un ejemplo).Distwave escribió:Habría que implementar el modo CGA, sus paletas, etc tanto en el hardware como en la BIOS. El mayor problema es que tenemos la FPGA a tope, pero seguramente se podría eliminar algo de lógica (por ejemplo el modo 640x480x16 está implementado, pero como puedes ver en el Visual Player no hay memoria de video suficiente para que sea usable)
La verdad es que no lo tengo claro. En el papillio el bus va a 80 MHz, así que no es problema del diseño original. Es posible que mis modificaciones hayan afectado a la estabilidad del core y el límite ahora sea inferior. Tengo que probar a sintetizar para el prototipo V3, que lleva una memoria SRAM más lenta, a ver si el límite sigue en los 50 Mhz o se reduce.Quest escribió:Respecto a la velocidad, supongo que esos 50Mhz son los máximos que se pueden conseguir en todo el diseño... en teoría la SRAM del ZX-Uno puede funcionar a 100Mhz, no?
Ya intenté meterle los dos SAA1099 para tener una CMS, pero no entra ni siquiera uno. Puse el sonido Tandy porque es realmente diminuto (y es lo malo, aunque lo quitemos no vamos a ganar recursos)Quest escribió:Si es por quitar, para mi gusto el sonido Tandy es prescindible. En todo caso también se podría intentar meter como prueba, el soporte CMS Game Blaster (la implementación del SAA1099, aunque no está perfecta, la tienes en el core de Sam Coupé).
Para que funcione por video compuesto / RGB tendrías que hacer lo contrario a un scandoubler, es decir: un módulo que grabaría dos líneas continuas en memoria, las mezclaría y la linea r esultante la reproduciría a la mitad de la frecuencia horizontal de refresco. Con eso obtendrías una velocidad de refresco medio compatible con NTSC.antoniovillena escribió:Una pregunta, ¿Sería muy complicado hacerlo PAL?
Me refería a resolución nativa. Los modos gráficos que hay actualmente son EGA 320x200x16 y MCGA 320x200x256 que ambos caben en PAL (no sé si en NTSC). El problema va a estar en el modo texto, que si queremos que sea medio legible con 200 líneas de resolución vertical no nos bastarán (a 25 filas sale a 8 pixel por carácter de alto). Tal vez con 12 pixeles y un mapa de caracteres escalado a mano con mas de 1bpp sea posible algo decente, incluso a costa de perder funcionalidades como la de redefinir caracteres.mcleod_ideafix escribió:Para que funcione por video compuesto / RGB tendrías que hacer lo contrario a un scandoubler, es decir: un módulo que grabaría dos líneas continuas en memoria, las mezclaría y la linea r esultante la reproduciría a la mitad de la frecuencia horizontal de refresco. Con eso obtendrías una velocidad de refresco medio compatible con NTSC.antoniovillena escribió:Una pregunta, ¿Sería muy complicado hacerlo PAL?
DistWave escribió:La verdad es que no he mirado como de complicado sería. Lo que si he visto es que la resolución que saca el core (independientemente del modo gráfico 320x200 o texto en que se encuentre) mi monitor Samsung la identifica como 720x400@70Hz