Montaje del ZXUNO

[antoniovillena]

ESXDOS http://www.esxdos.org/ supuestamente soporta FAT32 y SDHC mientras que ResiDos no lo hace. Hablo sin haber probado personalmente ni +3e ni el esxdos, así que puedo equivocarme. Creo que sí, como dices el +3e usa un formateado interno que no es FAT, por tanto no nos valdría para actualizar el firmware. Como tú veas, si lo que te echa para atrás (en el caso del DivMMC) es la falta de soporte del +3e yo me puedo encargar de hacerlo, tengo el código fuente del +2A/+3 compilable. No me sería muy complicado.

Por cierto si necesitas ayuda en lo que a software se refiere dímelo. Yo te puedo hacer los programas de tests que necesites. Por ejemplo uno que haga lecturas de la SPI y escriba los resultados en pantalla o algo así.

[mcleod_ideafix]

ESXDOS http://www.esxdos.org/ supuestamente soporta FAT32 y SDHC mientras que ResiDos no lo hace.

No hablo de soportar ResiDOS. Para soportar ResiDOS hace falta memoria con backup por batería, y al menos 256KB de ella dedicada a ResiDOS. Hablo de soportar +3e, que aunque se parecen, no son la misma cosa. De hecho, ResiDOS no soporta ZXMMC, sino ZXMMC Plus, que es un desarrollo más complejo. Tampoco soporta DivIDE, sino DivIDEPlus.

Por otra parte, aunque esxdos soporte FAT32, no soporta LFN, con lo que los nombres de archivos que pongas desde el PC aparecerán cortados cuando los listes desde el Spectrum.
Además, el soporte SD-HC no sólo ha de existir en software, sino en hardware: SD-HC no usa el protocolo SPI de las tarjetas SD/MMC, sino el protocolo SDIO (o algo así se llama) en el que se usan 4 líneas de datos a la vez, para una transferencia cuasi-paralela de datos, en lugar de serial. Ni ZXMMC, ni ZXUno soporta por hardware esta posibilidad. No sé si DIVMMC tiene cableadas las SD para que soporten este tipo de transferencia o no.

Creo que sí, como dices el +3e usa un formateado interno que no es FAT, por tanto no nos valdría para actualizar el firmware.

Arranca desde +3e y no hay problemas. Usando las llamadas al +3DOS puedes leer archivos desde la SD. Pero es que lo de soportar +3e no es unicamente por el hecho de que se pueda soportar la actualización de firmware desde él: es que hay software "serio" (Art Studio, Hisoft Devpack, Tasword II, etc) que ya han sido parcheados para poder ser usados en cualquier equipo compatible +3e.
¿Que el formato no es válido? ¿Por qué? Desde hace algún tiempo existen aplicaciones multiplataformas para pasar datos entre un PC y dispositivos con particiones IDEDOS.

Como tú veas, si lo que te echa para atrás (en el caso del DivMMC) es la falta de soporte del +3e yo me puedo encargar de hacerlo, tengo el código fuente del +2A/+3 compilable. No me sería muy complicado.

+3e es más que la ROM original del +2A/+3. De hecho las ROM's del proeycto +3e no tienen el test este que puedes hacer pulsando BREAK y luego QAZPLM, porque todo ese espacio lo ha usado Garry Lancaster para los nuevos canales, nuevos comandos, etc. Hay nuevos canales para pintar en 42 columnas, poder recoger en una variable de cadena el directorio de una unidad, etc. Hay nuevos comandos para poder particionar y formatear unidades IDEDOS desde el propio Spectrum, y comandos para por ejemplo, cargar snapshosts en formato SNA y Z80.

[antoniovillena]

No hablo de soportar ResiDOS. Para soportar ResiDOS hace falta memoria con backup por batería, y al menos 256KB de ella dedicada a ResiDOS. Hablo de soportar +3e, que aunque se parecen, no son la misma cosa. De hecho, ResiDOS no soporta ZXMMC, sino ZXMMC Plus, que es un desarrollo más complejo. Tampoco soporta DivIDE, sino DivIDEPlus.

Sí, yo tengo el ZXMMC+ y en su día probé ResiDOS. Ya te he dicho que el cambio para soportar +3e no tiene que ser muy complicado porque el +3e sólo usa los puertos SPI, no los de paginación. Es decir tan sólo sería cambiar un numerito por otro, aunque hasta que no lo intente no te puedo decir. Otra cosa muy distinta es cambiar ResiDOS o ESXDOS para que soporten el otro interfaz, puesto que usan paginación.

Por otra parte, aunque esxdos soporte FAT32, no soporta LFN, con lo que los nombres de archivos que pongas desde el PC aparecerán cortados cuando los listes desde el Spectrum.

A ver que es verdad que un FAT32 sin LFN es prácticamente lo mismo que FAT16. El problema es que hoy en día escasean las SD de poca capacidad, y en las de gran capacidad Windows te obliga a formatearlas en FAT32. Es más que nada para dar facilidades al usuario.

Además, el soporte SD-HC no sólo ha de existir en software, sino en hardware: SD-HC no usa el protocolo SPI de las tarjetas SD/MMC, sino el protocolo SDIO (o algo así se llama) en el que se usan 4 líneas de datos a la vez, para una transferencia cuasi-paralela de datos, en lugar de serial. Ni ZXMMC, ni ZXUno soporta por hardware esta posibilidad. No sé si DIVMMC tiene cableadas las SD para que soporten este tipo de transferencia o no.

Vaya pues esto no lo sabía. Entonces por lógica DivMMC no puede usar SPI, puesto que sí soporta SDHC.

Arranca desde +3e y no hay problemas. Usando las llamadas al +3DOS puedes leer archivos desde la SD. Pero es que lo de soportar +3e no es unicamente por el hecho de que se pueda soportar la actualización de firmware desde él: es que hay software "serio" (Art Studio, Hisoft Devpack, Tasword II, etc) que ya han sido parcheados para poder ser usados en cualquier equipo compatible +3e.
¿Que el formato no es válido? ¿Por qué? Desde hace algún tiempo existen aplicaciones multiplataformas para pasar datos entre un PC y dispositivos con particiones IDEDOS.

Pero si tienes para elegir entre +3e y otro SO que sí soporte FAT16/FAT32 para implementar las actualizaciones, yo elegiría el segundo caso. Ojo que estoy dando por sentado que +3e va a funcionar con DivMMC en breve, la elección sería Residos/+3e (ZXMMC+) o ESXDOS/+3e (DivMMC). El +3e es muy interesante y hay que soportarlo sí o sí.

+3e es más que la ROM original del +2A/+3. De hecho las ROM's del proeycto +3e no tienen el test este que puedes hacer pulsando BREAK y luego QAZPLM, porque todo ese espacio lo ha usado Garry Lancaster para los nuevos canales, nuevos comandos, etc. Hay nuevos canales para pintar en 42 columnas, poder recoger en una variable de cadena el directorio de una unidad, etc. Hay nuevos comandos para poder particionar y formatear unidades IDEDOS desde el propio Spectrum, y comandos para por ejemplo, cargar snapshosts en formato SNA y Z80.

Ya, pero no hay otra alternativa. Que yo sepa el código fuente del +3e no está disponible y es un proyecto que no está activo, por lo que no hay otra forma de soportar nuevos interfaces que vayan apareciendo. Si Garry Lancaster se pasase por WOS, le podríamos decir que lo hiciera él.

-- Actualizado 09 Feb 2014, 22:59 --

En el README.txt del ESXDOS pone que DivMMC usa SPI y no pone nada de SDIO. Lo único que se me ocurre es que se acceda a las tarjetas SDHC pero que se limite a los dos primeros gigas, sino no tiene mucho sentido lo de "SDHC support".

[mcleod_ideafix]

Sí, yo tengo el ZXMMC+ y en su día probé ResiDOS. Ya te he dicho que el cambio para soportar +3e no tiene que ser muy complicado porque el +3e sólo usa los puertos SPI, no los de paginación. Es decir tan sólo sería cambiar un numerito por otro, aunque hasta que no lo intente no te puedo decir. Otra cosa muy distinta es cambiar ResiDOS o ESXDOS para que soporten el otro interfaz, puesto que usan paginación.

El soporte de ZXMMC no es problema, pero... ¿por qué insistes en el ResiDOS?

A ver que es verdad que un FAT32 sin LFN es prácticamente lo mismo que FAT16. El problema es que hoy en día escasean las SD de poca capacidad, y en las de gran capacidad Windows te obliga a formatearlas en FAT32. Es más que nada para dar facilidades al usuario.

Tarjeta SD de gran capacidad = SDHC. SDHC no está soportado por el hardware de ZXUno. Por tanto, cualquier cosa existente, llámale DIVMMC o lo que sea, que esté usando la interfaz nativa de las tarjetas SD (porque la SPI no es nativa de las SD, sino de las MMC) no puede ser soportada por ZXUno.

Vaya pues esto no lo sabía. Entonces por lógica DivMMC no puede usar SPI, puesto que sí soporta SDHC.

Pues va a ser que me trago mis palabras. Estoy viendo los esquemáticos del DIVMMC y está usando SPI de toda la vida. ¿Seguro que el DIVMMC soporta SDHC? Respuesta: SI. En su momento leí el documento de SanDisk (cuando estaba haciendo el QLSD) y no sé por qué pensé que para SD-HC no podía usarse SPI, sino que había que hacerlo por SDIO.

Pero si tienes para elegir entre +3e y otro SO que sí soporte FAT16/FAT32 para implementar las actualizaciones, yo elegiría el segundo caso. Ojo que estoy dando por sentado que +3e va a funcionar con DivMMC en breve

¿Cómo va a ser eso si quien tiene los fuentes no sigue con el proyecto +3e? ¿Lo vas a parchear por tu cuenta? :O

El +3e es muy interesante y hay que soportarlo sí o sí.

Entonces... ¿se implementa un ZXMMC o un DIVMMC.... o ambos?

Ya, pero no hay otra alternativa. Que yo sepa el código fuente del +3e no está disponible y es un proyecto que no está activo, por lo que no hay otra forma de soportar nuevos interfaces que vayan apareciendo. Si Garry Lancaster se pasase por WOS, le podríamos decir que lo hiciera él.

También se le podría pedir que cediese el turno a otra persona para que hiciera el port para nuevos periféricos. Aparte de que ZXMMC y DIVMMC usen puertos diferentes, hay que ver si eso es lo único que cambia, o si por el contrario hay cambios en el comportamiento de los registros, etc. La cosa es... ¿dónde hay documentación sobre el modelo de programación del DIVMMC? No hay código fuente del diseño que va dentro de la CPLD. ¿Es DIVMMC un proyecto abierto? Pensaba que sí, pero por lo que veo en esta página:
http://aticatac.altervista.org/portale/?q=node/13
Falta precisamente la información que nos puede decir cómo "meter" DIVMMC dentro del ZXUno. Sospecho que será casi calcado a ZXMMC, pero... ¿dónde están esos puertos y cómo se usan?

[antoniovillena]

El soporte de ZXMMC no es problema, pero... ¿por qué insistes en el ResiDOS?

Porque he supuesto que estabas entre el dilema de implementar ZXMMC+ y DivMMC (SPI+paginación). Si sólo te planteas el puerto SPI y estás entre elegir los puertos que usa ZXMMC y DivMMC para sólo soportar el +3e está claro cuál es la mejor opción.

Tarjeta SD de gran capacidad = SDHC. SDHC no está soportado por el hardware de ZXUno. Por tanto, cualquier cosa existente, llámale DIVMMC o lo que sea, que esté usando la interfaz nativa de las tarjetas SD (porque la SPI no es nativa de las SD, sino de las MMC) no puede ser soportada por ZXUno.

Ya, me di cuenta después, por eso busqué la documentación del ESXDOS para comprobar que sí usa SPI.

Pues va a ser que me trago mis palabras. Estoy viendo los esquemáticos del DIVMMC y está usando SPI de toda la vida. ¿Seguro que el DIVMMC soporta SDHC? Respuesta: SI. En su momento leí el documento de SanDisk (cuando estaba haciendo el QLSD) y no sé por qué pensé que para SD-HC no podía usarse SPI, sino que había que hacerlo por SDIO.

¿Cómo va a ser eso si quien tiene los fuentes no sigue con el proyecto +3e? ¿Lo vas a parchear por tu cuenta? :O

Así es. Ya te digo que no sería un parche desde cero contando sólo con la ROM. Sería partiendo de este proyecto:

http://sourceforge.net/p/emuscriptoria/ ... /plusROMs/

Entonces... ¿se implementa un ZXMMC o un DIVMMC.... o ambos?

Mi sugerencia es soportar DivMMC en el ZX-Uno y yo me encargaría de que el proyecto +3e funcionase.

También se le podría pedir que cediese el turno a otra persona para que hiciera el port para nuevos periféricos. Aparte de que ZXMMC y DIVMMC usen puertos diferentes, hay que ver si eso es lo único que cambia, o si por el contrario hay cambios en el comportamiento de los registros, etc. La cosa es... ¿dónde hay documentación sobre el modelo de programación del DIVMMC? No hay código fuente del diseño que va dentro de la CPLD. ¿Es DIVMMC un proyecto abierto? Pensaba que sí, pero por lo que veo en esta página:
http://aticatac.altervista.org/portale/?q=node/13
Falta precisamente la información que nos puede decir cómo "meter" DIVMMC dentro del ZXUno. Sospecho que será casi calcado a ZXMMC, pero... ¿dónde están esos puertos y cómo se usan?

Se le puede pedir permiso y se puede hablar directamente con los desarrolladores para que nos den información, pero no creo que la den tan fácilmente. Desgraciadamente en esta escena la gran parte de los proyectos en SO es código cerrado. Yo sospecho lo mismo que tú, y aplicando la navaja de Occam...

-- Actualizado 09 Feb 2014, 23:29 --

Con lo que dice velesoft en este post:
http://zx.pk.ru/showpost.php?p=623752&postcount=907

La documentación del ZXMMC (parte SPI) y la documentación del DivIDE (parte paginación RAM) creo que hay suficiente información.

[mcleod_ideafix]

Con lo que dice velesoft en este post:
http://zx.pk.ru/showpost.php?p=623752&postcount=907

La documentación del ZXMMC (parte SPI) y la documentación del DivIDE (parte paginación RAM) creo que hay suficiente información.

SIIIII SEÑOOOOOOOOOOOOOOR. Esto es lo que necesitaba:

Here is paging port #E3 of original DIVIDE:
D0-D1 = 8kB ram page 0-3
D2-D5 = unused
D6 = bit mapram
D7 = bit conmem

And here is paging port #E3 of DIVMMC:
D0-D5 = 8kB ram page 0-63 (for full 512kB memory)
D6 = bit mapram
D7 = bit conmem

Functionality of memory paging, layout and mapping is (supposedly) compatible with DIVIDE interface. Only more ram is usable.
All old DIVIDE systems with IDE access are on DIVMMC unusable, because IDE ports here not exist. Only ESXDOS system exist for DIVMMC.

DIVMMC SD port functionality is same as ZXMMC interface, only address of SD ports are different:
- port #1F(ZXMMC) for writing is replaced with new port #E7(DIVMMC)
- port #3F(ZXMMC) for read/write data is replaced with new port #EB(DIVMMC)

Y enfatizo esa línea de arriba: la interfaz SPI del ZXMMC y la del DIVMMC son idénticas: sólo cambian los puertos. Eso significa que podemos implementar ambas interfaces, y dar soporte tanto a ESXDOS a través de DIVMMC como a +3e a través de ZXMMC, o bien implementar unicamente DIVMMC y parchear directamente las ROM's del +3e cambiando 1F por E7 y 3F por EB donde corresponda

[antoniovillena]

Así es. La historia es más o menos así:

• Alessandro Poppi diseña Badaloc, un clon como el ZX-Uno pero aproximado, por aquel entonces Chris Smith no había aparecido en escena.
• Como proyecto secundario sale el proyecto ZXMMC. Un interfaz sencillo que sólo abarca la parte SPI. Para hacerlo atractivo (que se puedan cargar archivos .TAP por ejemplo) hay que recurrir a paginación.
• El proyecto avanza a su versión 2.0, lo llama ZXMMC+ y le da soporte de paginación.
• Los SO de la época dan soporte a ZXMMC, el +3e sólo necesita el puerto SPI, ResiDOS hace uso también de paginación.
• Pasan los años y el proyecto no tiene mucha difusión.
• El que lo peta es DivIDE, sobre todo la parte que usa CF en lugar de disco duro.
• Pasan los años y las tarjetas CF pierden popularidad. Por suerte hay un segmento fotográfico de cámaras de alta gama que las necesita por su velocidad de transferencia. Por el contrario las SD ganan popularidad.
• Se dan cuenta que tarde o temprano hay que migrar a SD, así que sacan un interfaz SD muy parecida a ZXMMC+. El problema es que la mayor parte del software está escrito para DivIDE, entonces deciden que tendrá los mismos puertos SPI (en otras direcciones) pero la misma paginación que el DivIDE, o una muy parecida (muy distinta a la del ZXMMC+).

[mcleod_ideafix]

Así es. La historia es más o menos así:
[list]
[*]Alessandro Poppi diseña Badaloc, un clon como el ZX-Uno pero aproximado, por aquel entonces Chris Smith no había aparecido en escena.
[*]Como proyecto secundario sale el proyecto ZXMMC. Un interfaz sencillo que sólo abarca la parte SPI. Para hacerlo atractivo (que se puedan cargar archivos .TAP por ejemplo) hay que recurrir a paginación.

En realidad creo que ZXMMC+ salió después de que +3e soportara ZXMMC. Recuerdo cuando le compré algunas PCB's a Alessandro para hacerme mis ZXMMC (en su día hice dos tarjetas, y creo que podría aún hacer otras dos, pues debo tener por algún lado las PCB's sobrantes), y no vi nada del ZXMMC+. Luego más tarde sí que lo vi como continuación del proyecto.

De hecho, fue gracias a/por culpa de que puse la interface ZXMMC a uno de mis +3 que surgió la necesidad de a ver cómo transfería ficheros a la tarjeta en el formato que necesita +3e, y así nació la utilidad "3e" que permite leer y escribir en este tipo de particiones. Luego otro italiano usó el soporte de "backend" de 3e para escribir un frontend que es el que algunos conocen como Strowsaw, para intercambiar ficheros entre tarjetas formateadas con IDEDOS y el PC.

Eso me recuerda que algún año de estos me haré un ZX-Matrix, del que también tengo las PCB's. Ese tiene tela, más aún que el ZX-Uno... :O

[antoniovillena]

Pues yo me compré la versión siguiente, la ZXMMC+. Pero compré la versión más capada que había, no tenía ni puerto, ni RS232, ni Flash y sólo uno de los 2 zócalos para SD. Tenías que cargar el SO (ResiDOS) desde cinta y se almacenaba en RAM. Por suerte había una pila de botón que hacía que la RAM no se borrase, pero en la práctica cada vez que lo quería usar tenía que hacerlo, no sé porqué con el tiempo se borraba.

El proyecto +3e lo conozco de oídas pero nunca me lo instalado. También sabía que tú estabas detrás del programa que transfiere archivos para este tipo de particiones. Si es que al final siempre somos los mismos los que hacemos los cacharritos y el software para los cacharritos.

-- Actualizado 10 Feb 2014, 00:32 --

Yo también tuve un intento (fallido) de interfaz hace unos años, se llamaba andros. Aquí hay un hilo donde hablamos de él.

http://es.comp.sistemas.sinclair.narkiv ... cto-andros

La parte software, que es la única que estaba hecha, imitaba al explorador de windows. Vamos que si escribes poco a poco las letras del archivo al final das con él, también te puedes mover con los cursores o con las teclas Shift+QAOP. Al principio tarda en arrancar porque ordena alfabéticamente la lista de ficheros (se supone que en FAT están desordenados).

[mcleod_ideafix]

Volviendo al tópico en cuestión. Ha llegado el test6.

El test6 es basicamente un Spectrum con el hardware de un +2A/+3 (128K RAM, AY-3-8912, modo all-RAM) pero con una única ROM de 16K con el firmware estándar de Spectrum 48K. Vamos, que cuando arranques, verás el mensaje de copyright de siempre. También están incluidos los modos ULAplus y Timex hicolor.

Aquí por ejemplo se puede ver un pequeño programa que hice para demostrar el uso de la pantalla shadow y música por interrupciones: dos pantallas se muestran, y una de ellas en plan cortina va tapando poco a poco a la primera y después la descubre. De fondo suena el AY-3-8912.



Y aquí, la prueba de que el modo all-RAM es funcional: el emulador de PacMan de Simon Owen, que solo funciona en +2A/+3



El teclado, el sonido y la entrada EAR ya están incorporadas. EAR se porta muy bien, al menos con un iPhone que estoy usando para cargar cositas usando SpeccyTape. En cuanto a la salida de sonido, de momento es monoaural. Un módulo mezclador hace la mezcla de las señales MIC, SPK, EAR y el AY. En un Spectrum estándar, la entrada EAR está directamente cableada al altavoz, y por eso oimos el ruido de la carga. En este clon no ocurre así, y por tanto EAR se toma como una fuente de sonido más a mezclar con las demás.

Esto tiene una ligera ventaja sobre el método tradicional, y es que ahora, podemos asegurar que si tú no oyes el sonido de carga, el Spectrum tampoco lo oirá. Si tú lo oyes mal, el Spectrum también. Antes podías estar escuchabndo ruido de carga y el Spectrum sin inmutarse. También nos permite dosificar de forma racional el volumen de carga: en el momento en que el ruido se escucha bien, no tiene sentido seguir subiendo el volumen, porque no lo escucharemos más fuerte.

Sobre el teclado: la interfaz de teclado PS/2 implementada es de sólo entrada, del teclado al clon. No se ha implementado comunicación en sentido contrario. Esto podría ser un problema para los teclados que son duales (PS/2 y USB, y que para usarse con PS/2 tienen un adaptador) ya que, por lo que recuerdo, este tipo de teclados por defecto se autoconfiguran en modo USB, y sólo si reciben la trama de reset en formato PS/2, es cuando conmutan al modo PS/2. Esto puede que no sea un estándar y en algunos teclados no haga falta hacerlo. Sería conveniente poder probar con varios teclados de este tipo a ver si lo que acabo de decir es norma, o es sólo una opción de implementación.

Para deleitarse con los colores de ULAplus, en el repositorio hay un nuevo directorio, "software", donde estoy colgando algunas cosillas que tenía hechas de cuando comencé a implementar la ULAplus (también está el programa que testea la pantalla shadow). Esta instantánea corresponde a un slideshow de imágenes en formato hires del Commodore 64.



¡Ah! una cosilla. Que me asusté cuando probé el legendario Jet Pac, y al comenzar la partida se me ponía la pantalla en negro, aunque podía seguir jugando, pero sin ver nada. Resulta que Jet Pac escribe inadvertidametne al puerto 32765, el de paginación (???) y activa la pantalla shadow. Así que para tener 100% de compatibilidad con 48K, al arrancar el sistema hacer un OUT 32765,32 para desactivar la paginación.



En cuanto a timmings, aún no he tenido tiempo de hacer muchas pruebas, pero la cosa promete. La Shock Megamo se porta (y suena muy bien)