Avances en el desarrollo del ZX-Uno

[jepalza]

El "Papilio Pro" lleva un "XC6SLX9 de 144 pines TQG", podría probar a meter el ZXUNO a ver cuanto nos sobra. Pero no puedo hacer pruebas este fin de semana.

[JULIO]

He cargado el test13, luego el testrom.tap y me aparece el logo de esxdos, detecta la sdhc y se cargan los archivos y me he pasado
por trd.speccy.cz porque no conseguía cargar una demo en formato .scl, he descargado el trx2x y finalmente se genera
un fichero .trd a partir del scl.
Con el fichero scl tras invocar el trdos si intentaba cat o run, se colgaba.
Con el fichero pasado a .trd, lo he podido cargar sin problemas, pero al final, si pulso NMI (crtl+alt+F5) a veces muestra el logo esxdos y a veces se resetea y se queda en modo48 +3e, teniendo que cargar de nuevo el testrom.tap.
el fichero es el binary_love de:
http://www.pouet.net/prod.php?which=1576
¿esto es normal?
...acabo de ver el post de Mc Leod en esxdos.org...no es normal, se queda bloqueado o se resetea.

[aowen]

I gather there's been some interest in having a per-pixel color mode. I deliberately left that out of the original ULAplus because it uses a lot of gates. Also I don't see any point adding modes which can't be used by existing software. However, I do have a design for a per-pixel mode which can be used by existing software. You get 8 colors from a palette of 256 (same palette as ULAplus). This will enable all mono 48K games to be recolored without any hacking. Here's an example:

Creo entender que existe algún interés en tener un modo de color-por-pixel. Dejé eso fuera del ULAplus aposta porque usa muchas puertas. Además no veo razón para añadir modos que no pueden ser usados por el sofware existente. Sin embargo, sí que tengo un diseño de color-por-píxel que puede ser usado por el software existente. Puedes tener 8 colores de la paleta de 256 (la misma paleta que el ULAplus). Esto permitiría que todos los juegos monocromo 48K pudieran ser re-coloreados sin ningún “hacking”. Aquí tenéis un ejemplo:

[VELESOFT]

I gather there's been some interest in having a per-pixel color mode. I deliberately left that out of the original ULAplus because it uses a lot of gates. Also I don't see any point adding modes which can't be used by existing software. However, I do have a design for a per-pixel mode which can be used by existing software. You get 8 colors from a palette of 256 (same palette as ULAplus). This will enable all mono 48K games to be recolored without any hacking. Here's an example:

Also good way is use SAM COUPE palette for all 16 ZX colors. Here you can see ZX games ported from ULA plus to SAM COUPE (ZX mode with custom palette):
http://velesoft.speccy.cz/sam_zx128.htm

SAM COUPE color palette:


ZX games on SAM COUPE :




Each or 16 zx colors can be defined via single OUT command from ZX basic (ideally in basic loader before load or start game)

[mcleod_ideafix]

Con el fichero pasado a .trd, lo he podido cargar sin problemas, pero al final, si pulso NMI (crtl+alt+F5) a veces muestra el logo esxdos y a veces se resetea y se queda en modo48 +3e, teniendo que cargar de nuevo el testrom.tap.
el fichero es el binary_love de:
http://www.pouet.net/prod.php?which=1576
¿esto es normal?
...acabo de ver el post de Mc Leod en esxdos.org...no es normal, se queda bloqueado o se resetea.

Como ya comenté posts atrás, cuando presenté el test12, la NMI del ESXDOS no funciona. No sé por qué. El mismo día que lo probé puse el post en el foro de ESXDOS, pero me da que ese foro está muerto muerto. No ha habido actividad en él desde que posteé.

La NMI, como tal cosa, funciona, porque por ejemplo en Open SE IV, si pulsas NMI, obtienes un L Break into program. Me da que es la propia rutina que se ejecuta en ESXDOS (NMI.SYS), que usará alguna instrucción o característica no implementada en el core T80 (para variar).

De todas formas, para probar los TRD o lo que sea, no necesitas la NMI: montas el TRD con .vdisk, luego invocas al TRDOS con RANDOMIZE USR 15616 y acto seguido cargas el programa que sea con LOAD "nombre" (y luego RUN). En la documentación de ESXDOS advierten que no funciona con cualquier TRD, sino sólo con los "recortados" (sea lo que sea lo que signifique eso). También tened en cuenta que estos TRDs pueden tener programas para Scorpion o Pentagon, y que esos bichos no son lo que hay implementado en ZX-Uno.

[VELESOFT]

DIVMMC need more than 32kB divide ram. Than number of 8kB ram pages is used in DIVMMC on ZX-UNO ? Original DIVMMC use only two memory sizes - 128kB sram(16x 8kB ram page) or 512kB sram(64x 8kB ram page). DIVMMC in V6Z80P clone use 256kB divide ram. First 32kB ram (4 ram pages) and 8kB eeprom is used for esxdos system functionality. Next (5th) page is used for backup zx ram block during NMI menu functionality...

[mcleod_ideafix]

OMG! is it that???? I will fix the DIVMMC module. Thanks a lot!!

[aowen]

Also good way is use SAM COUPE palette for all 16 ZX colors.

That's a bad way for a clone that already supports ULAplus.

Esa no es una buena opción para un clon que ya incluye ULAplus.

OMG! is it that???? I will fix the DIVMMC module. Thanks a lot!!

I should have thought of that. However, personally I'd rather have the SE Basic IV functionality than the loader menu. I wonder if there would be a way to allocate different NMI buttons to different function keys. So F0 = Chloe NMI, F15 = divMMC NMI?

Debería haber pensado en eso. Sin empargo, personalmente preferiría tener la funcionalidad del SE BASIC IV en vez del menú cargaador. Me pregunto: ¿Habría alguna manera de asignar diferentes botones NMI a las distintas teclas función?. Así F0= Chloe NMI, F15=divMMC NMI.

[VELESOFT]

I am in contact with author of ESXDOS. He cannot access board.esxdos.org. He says :

Supported divmcc configs are only 128kB or 256kB or 512kB divide ram.
Esxdos support TRD images with any size (also 640kB) up to 1024kB.

-- Actualizado 23 Mar 2014, 13:12 --

Also good way is use SAM COUPE palette for all 16 ZX colors.

That's a bad way for a clone that already supports ULAplus.

SAM COUPE palette port can exist parallel with ULAplus (it's very easy). I plan add sam coupe palette support to ZX games and make web page for it. (similar as page for K-MOUSE software).

-- Actualizado 23 Mar 2014, 13:16 --

I am in contact with author of ESXDOS. He cannot access board.esxdos.org. He says :

Supported divmcc configs are only 128kB or 256kB or 512kB divide ram.
Esxdos support TRD images with any size (also 640kB) up to 1024kB.

-- Actualizado 23 Mar 2014, 13:12 --

Also good way is use SAM COUPE palette for all 16 ZX colors.

That's a bad way for a clone that already supports ULAplus.

SAM COUPE palette port can exist parallel with ULAplus (it's very easy). I plan add sam coupe palette support to ZX games and make web page for it. (similar as page for K-MOUSE software). SAM COUPE palette support will bigger than ULA plus support.

[mcleod_ideafix]

El "Papilio Pro" lleva un "XC6SLX9 de 144 pines TQG", podría probar a meter el ZXUNO a ver cuanto nos sobra. Pero no puedo hacer pruebas este fin de semana.

En una síntesis rápida, me he quedado asombrado. Usando el test12, pasamos de usar un 89% de los recursos de la Spartan 3-250 a usar menos del 60% con una LX9. Se ve que nuestro diseño tiene una gran carga combinacional, y no es para menos: tanto el teclado como el propio T80 están gobernados por megabloques combinacionales, y se ve que la Spartan 6 está más optimizada para esas cosas, con sus LUTs de 6 entradas (lo que en la Spartan 3 ocupa 2 LUTs, aquí ocupa 1, siempre y cuando sea lógica combinacional).

La síntesis da ahora unos warnings que no me daba antes, relacionados con la implementación de dos pequeñas memorias de doble puerto: una dentro del T80, y la otra es la paleta de la ULAplus. Creo que es que ahora esas memorias se implementan con BRAMs que tienen más de dos puertos y claro, "sobran" puertos y de ahí los warnings. También he visto warnings un poco más extraños haciendo referencia a relojes generados por lógica combinacional, cosa que no ocurría antes. Estos warnings me los da en el módulo AY-3-8912, y juraría que en ese módulo escogí la versión síncrona, no la que usa latches.

Por otra parte, los warnings que obtenía con la Spartan 3 sobre multiplexores que no se han podido unir (para crear circuitos combinacionales más gordos) ya no me da, cosa lógica por lo que he comentado antes de las LUTs de la Spartan 6. Tampoco tengo "clock skew" en las señales rápidas (14MHz(, y eso es bueno porque significa que el P&R no ha tenido que mover módulos a sitios esotéricos (vamos, que tiene más espacio para posicionar y rutar).

De todas formas, antes de darle a Superfo con el palo de rutar placas, dejadme que consulte con mis compañeros de departamento ahora que ya me van a dar el alta médica y puedo volver a la universidad . Ellos tienen mucha más experiencia que yo sobre esta familia, y así os doy una opinión más certera (de momento mi opinión es muy buena, ¡yum!).

Una cosa que me ha echado para atrás con la Spartan 6 para otros proyectos (a éste le afecta, pero poco, creo), es que los pines de la Spartan 6 no están protegidos con diodos de clamping. Eso en principio hace al chisme un poco más delicado a los "overshoots" y "undershoots", y dificulta su interfaz con sistemas que trabajen a 5V (en nuestro caso, el teclado PS/2). No sé si lo hace más delicado a la electricidad estática (esos deditos desnudos tocando los pinchos del conector de expansión). Como digo, consultaré con mis compañeros a ver qué me dicen.