mcleod_ideafix escribió:Dependemos de un montón de software "de terceros" para que ZX-Uno sea ZX-Uno. Para empezar, el ISE de Xilinx.
Tío, no me hiles tan fino, que sabes perfectamente a lo que me estaba refiriendo. El ISE lo usáis los que desarrolláis, no el usuario. No creo que haga falta aclarar más este punto.
mcleod_ideafix escribió:Sólo si quieres actualizar tú el ESXDOS, y en caso de que así sea y la nueva versión sea incompatible en API con la anterior, se cogen las utilidades, que para eso dejamos los códigos fuente y se modifican. Habida cuenta del tiempo que pasa entre una actualización y otra de ESXDOS, me da que cambios de release, poquitos.
Estupendo, dile al usuario que se modifique y se compile el código. Puede que no sea "casual", pero tampoco tiene por qué ser técnico.
Respecto a los cambios de release, cierto, pero probablemente el ZXUNO salga antes del cambio de LFN (para mi gusto MUY relevante), y no solo yo, sino la mayoría va a querer tener ese soporte. Me juego una mano
El resto.. un misterio.mcleod_ideafix escribió:La cantidad "nada despreciable" de demos, ¿cuántas son? Porque sólo me he encontrado con una que le pase eso. Por el contrario, sí que hay una cantidad nada despreciable de demos que si no tienes ESXDOS y su emulación de TRDOS, no vas a ver ni en pintura, porque no tienen versión TAP y sí TRD.
Ya, pero no recuerdo haber dicho nunca jamás que haya que eliminar ESXDOS (muy al contrario). ¿por qué diantres íbamos a dejar de usarlo para cargar TRDs? no lo entiendo.
mcleod_ideafix escribió:Y el problema con los juegos mojonios y similares no es que ESXDOS interfiera, sino que al arrancarse la máquina en modo 48K, aunque tengas los 128K y lo demás, no tienes las variables del sistema que siguen a los valores de los puertos. La demo de Paralaktica no tiene ningún problema con ESXDOS, por cierto: tanto la versión TRD como la TAP, con los timmings de 128K, las arranco desde ESXDOS.
Vale, entonces ahora tú, yo y los probables 20 o 25 usuarios que leen este hilo lo sabemos. Eso es irrelevante. Cuando uno carga y no va, y no es técnico (Aunque no sea tampoco "casual"), no tiene por qué saber el motivo.
mcleod_ideafix escribió:Y por último: recordad que esto es una plataforma. Cada uno la personaliza como quiere. No es el Vega: enchufar y listo. Esto no va encaminado al usuario "casual" aunque se le dan muchas facilidades a los usuarios que sólo quieran jugar. De hecho, ESXDOS y su menú NMI es lo más sencillo que le puedes echar a un usuario.
Sin duda. Pero reitero que el no ser "casual" no implica que se sea técnico. En cualquier caso coincido contigo con respecto a ESXDOS y su NMI. Es lo mejor que hay ahora mismo. Insisto, ¿Alguien ha dicho que haya que eliminarlo?
[/quote]mcleod_ideafix escribió:Antonio pensaba dar soporte de keymaps en la BIOS para que cada uno puede elegir el suyo en el arranque. La facilidad hardware esta ahí (el poder cambiar de mapa). Ahora hay que implementar el software. No sé vosotros, pero yo no tengo la necesidad de cambiar de mapa cada dos por tres. Tengo el que me gusta y ya está. En FPGA sólo cabe un mapa, no puedes tener más de uno metido en BRAM, porque como ya he comentado, hasta no tener implementado el scandoubler no sabré cuánta BRAM me quedará libre.
Bueno, tú lo has dicho, tú no tienes la necesidad de cambiar el mapa. Quién sabe el resto. Yo por ejemplo (aunque sea irrelevante, lo comento porque casualmente lo cambio mucho ahora), lo cambio porque tengo un miniteclado (de los que ocupan un palmo de ancho) que uso cuando pongo el ZXUNO en el escritorio donde tengo poco espacio y tiene la distribución US. Afortunadamente gracias a tu implementación reciente de los keymaps puedo activarlo con el plugin de ESXDOS. Cuando uso el ZXUNO en un lugar con más espacio uso un teclado completo con mapa ES.
Respecto a la cantidad de mapas, justo en el post anterior Antonio ya se ha pronunciado al respecto. Me parece interesante.
Con respecto al scandoubler, por supuesto me parece más importante. No obsante no parece que sea ya un obstáculo por lo mencionado justo en la línea anterior.
El reproductor PZX es un experimento, y queda chulo y tal, pero no es algo en lo que vaya a trabajar más de momento. La implementación que tengo es limpia, y el uso de una memoria externa la simplifica mucho.
O espera.... no. Entiendo que tú quieres que la ROM del bootloader se invoque con esta NMI especial. En la dirección 0066h tendrá que haber código para poner en MASTERMAPPER la página de SRAM que hayamos elegido para tener el gestor NMI (pongamos que sea la 13) y también estará la instrucción RETN en una posición especial para desde ahí hacer el desmapeo. Durante la etapa de BIOS, además de cargar la ROM de usuario y la ROM de ESXDOS, se cargaría la ROM NMI a la página de SRAM 13