Avances en el desarrollo del ZX-Uno

[aowen]

Doesn't work:
- If I trigger any BASIC error, for example, trying to print a non existent variable, the machine hangs for about a minute or so, and then it shows the message "Out of memory, 0:1". The BASIC program that could be in memory becomes corrupted.
- If I generate lots of output on screen (for example, listing a large directory using .ls ) and the Scroll? message is presented, pressing SPACE, or N to stop scrolling causes nothing, or the machine resets . Precisely: if I run a program like this:

Código: Seleccionar todo

10 PRINT 3: GOTO 10

Pressing N or SPACE is response to the Scroll? question doesn't do anything. I have to stop with NMI/BREAK.

If I list a large directory with .ls , pressing SPACE or N in response to Scroll? causes the machine to reset.

I suspect this is down to the differences in the error handler and scroll code in SE Basic IV. Hopefully it won't take too much work to resolve these issues.

[aowen]

He escrito un conjunto de pruebas para el Chloe 280SE. Pone a prueba la mayor parte de la memoria RAM y todos los modos de vídeo.

https://dl.dropboxusercontent.com/u/15659782/SEtest.zip

[mcleod_ideafix]

¡Muchas gracias! Con esto ya puedo ponerme a implementar la MMU horizontal. Probablemente tenga alguna pregunta para ti si no entiendo algún detalle del funcionamiento de esta MMU. De momento, repasaré la documentación que tú escribiste.
----
Thanks a lot! I can now begin to implement the horizontal MMU. I will probably have some questions about the internal workings of this MMU, but first, I will review the documentation you wrote about the subject.

[TallerSeverino]

Voy a hacer una prueba con el permiso del administrador, he empezado a traducir algunos de los posts al castellano, a ver si os parece bien así:

Re: Avances en el desarrollo del ZX-Uno
por superfo » 10 Mar 2014, 09:04


Hola.
He intentado el test11 y funciona muy bien
¿Cómo puedo unir el archivo rom dentro del archivo MCS? Me gustaría usar la versión inlgesa de la rom 3e.
¡Gracias!


Re: Avances en el desarrollo del ZX-Uno
por jepalza » 10 Mar 2014, 12:25
superfo escribió:

Hola.
He intentado el test11 y funciona muy bien
¿Cómo puedo unir el archivo rom dentro del archivo MCS? Me gustaría usar la versión inlgesa de la rom 3e.
¡Gracias!

Lo primero; necesitas limpiar el MCS en el BIT (tld_zxuno.bit). Abrelo en IMPACT (¡Tú ya sabes!)
Con éste MCS ya generado, en el prompt de MSDOS (y con la utilidad SREC), escribe:
srec_cat.exe tld_zxuno.mcs -intel spectrum_rom.bin -binary -offset 0x30000 -o final.mcs -intel

El offset (desplazamiento) 0x30000 es muy importante, es el principio del espacio de la ROM para que se pueda leer en el ZXUNO.


Re: Avances en el desarrollo del ZX-Uno
por superfo » 11 Mar 2014, 04:34

¡Gracias Jepalza!


Re: Avances en el desarrollo del ZX-Uno
por aowen » 14 Mar 2014, 16:03

Muy interesante. Parece que nadie está leyendo el hilo en foro.speccy.org, así que haré “re-post” aquí, con unos pocos cambios una vez que acabo de leer este hilo.
Veo que el zx-uno está ejecutando SE basic IV con éxito. Esto quiere decir que el zx-uno es más o menos equivalente al Chloe 140SE: http://www.zxshed.co.uk/sinclairfaq/ind ... hloe_140SE
Sin embargo, esa es la versión 4.1 del SE Basic, que tiene muchos fallos (bugs). No tengo pensado arreglarlos, así que sugiero usar en su lugar la versión 4.0.1 (incluida en la actual versión de Fuse). No tiene todas las características del 4.1, pero todavía incluye el modo de 80 columnas y es estable. Si hay algunas características del 4.1 que la gente quiera realmente usar, se me puede convencer de trasladarlas (back-port) a la versión 4.0.
Eso dependería de si el ZX-Uno ofreciera un core Chloe 280SE completo.
No debería de ser mucho trabajo mejorar (upgrade) hasta llegar a todas las especificaciones del core Chloe 280SE.
http://www.zxshed.co.uk/sinclairfaq/ind ... hloe_280SE
El Chloe 280SE es una versión reorganizada (rationalized) del ZX Spectrum SE:
http://www.zxshed.co.uk/sinclairfaq/ind ... pectrum_SE

Hacer el core compatible con el Chloe 280SE y con SE Basic IV como el firmware nativo permititía a la máquina ejecutar los siguientes emuladores sin reprogramar la FPGA:
Acorn BBC B (unfinished)
Apple I
Commodore VIC-20
Compukit UK101
Galaksija
Jupiter Ace
Phillips Videopac G7000
Sinclair ZX80
Sinclair ZX81
Sinclair ZX Spectrum 16K
Sinclair ZX Spectrum 48K
Sinclair ZX Spectrum 128 (1985)
Sinclair ZX Spectrum 128 (1986)
Sinclair ZX Spectrum +2
Timex Computer TC2048
Timex Computer TC2068
La emulación del TC2068 permite el acceso a todo el catálogo basado en cintas del Timex, e incluso algún sofware ROM de WoS: http://www.worldofspectrum.org/tmx/
También permitiría un correcto funcionamiento de tiempos (timing) ejecutando desde IF2 y cartuchos MikroPlus (el +3 tiene los primeros 16K de RAM contenida (contended) en el modo all-RAM)
Shadow of the Unicorn
Gyruss
Panama Joe
Popeye
Q*Bert
Death Star Battle
Star Wars
Loco Motion
Montezuma's Revenge
Space Raiders
Chess
Planetoids
Hungry Horace
Backgammon
Horace and the Spiders
Jet Pac
Pssst
Tranz Am
Cookie

Ahora hay una discusión en WoS sobre la construcción de Loki, para seros sinceros creo que ZX-Uno y un core Chloe 280SE sería una mejor idea: http://www.worldofspectrum.org/forums/s ... hp?t=46911

Re: Avances en el desarrollo del ZX-Uno
por aowen » 15 Mar 2014, 11:42


Todos los errores en el core del T80 se conocen y se han arreglado. Creo que tanto Crhis Smith como Jeff Braine tienen los detalles. Les preguntaré.
Edición: Les he preguntado y aparentemente los arreglos (fixes) de Chris son específicos para su implementación, pero podéis contactar con él y comparar notas.
All the bugs in the T80 core are known and fixed. I think both Chris Smith and Jeff Braine have the details. I'll ask them. Edit: I did ask them, and apparently Chris's fixes are specific to his implementation, but you might want to check in with him and compare notes.


¿ Significa eso que en el ZXUNO podemos ejecutar cualquier sistema Z80 solo poniendo el "core" en una tarjeta SD (por ejemplo)?

Bueno, en el arranque tienes que configurar la FPGA para que sea cualquier tipo de spectrum que desees. Una de esas opciones es un Chloe 280SE. No se mucho de los detalles del diseño, pero si el core está almacenado en la tarjeta SD y se carga en el arranque entonces sí, sólo necesitarías el core Chloe 280SE en la tarjeta SD para ejecutar programas para cualquier spectrum a excepción del +3. El Chloe 280SE no es compatible con +3DOS, pero no hay muchos programas que necesiten el +3DOS. Chloe 280SE combina la paginación del Timex y del Spectrum 128 y por lo tanto puede emular el TC2068 y sistema con rom doble como la mayoría de spectrums 128K. Cada emulador ocupa sólo el espacio necesario para la ROM y un cargardor pequeño, el cual está normalmente entre 16k y 32k, y por supuesto es posible usar versiones con otros idiomas. Las roms de 16K no requieren parcheo (patching), las de 32K sí para cambiar el modo en que funciona la paginación, pero esto no es problema ya que los desemsamblados están disponibles para las roms 128K.

-- Actualizado 15 Mar 2014, 10:58 --
mcleod_ideafix escribió:Piensa por ejemplo que con la flexibilidad del mapeo de memoria del +3 ya se pueden ejecutar emuladores de PacMan. El 280SE tiene aun mayor flexibilidad. No sería un clon, sería una emulación (parcial).

Aunque puedes ejecutar software en el espacio de direcciones desde 0x0000 hasta 0x3FFF en el +3, solo puedes acceder a una página de RAM de 16K y está contenida (contended) (y todo funciona más lento). El Chloe 280SE tiene dos bancos laterales (sideways banks) de 64K, paginables en trozoz de 8K, y las únicas páginas RAM que están contenidas (contended) son las páginas de vídeo (el banco 5 y 7).

Edición: He eliminado los originales en inglés.

[antoniovillena]

Gracias TallerSeverino por el esfuerzo que estás haciendo en la traducción.

McLeod, viendo el mapa de memoria hay una cosa que me gustaría cambiar. Es la ubicación de la ROM del DivMMC, son 8K que creo que nos molestan. Mi sugerencia es pasarlos a BRAM y tener a nuestra disposición 128K contiguos para ROM de sistema. Ya sé que si lo pasamos a BRAM perdemos flexibilidad a la hora de actualizar su contenido, pero es que tampoco es que haya muchas versiones de esa ROM y el hecho de que ocupe 8K en lugar de 16K lo hace menos manejable. Sé que la 250E tiene sólo 24K de BRAM, así que si necesitas más BRAM para otros menesteres (ULAplus) puedes quitársela a los 16K de boot donde va la BIOS. Así tendríamos 8 bancos de ROM contiguos (128K) en los que poder implementar un superspectrum, necesitaríamos un tercer bit (además del bit 4 del 7ffd y del bit 2 del 1ffd) para direccionarlos.

Por otro lado tengo dudas a la hora de buscar 3 componentes. El primero es el filtro de choke, ¿nos valdría este?

http://www.aliexpress.com/item/TDK-Comm ... 80079.html

El segundo es el ferrite bead, no sé si este nos vale:

http://www.aliexpress.com/item/NEW-0805 ... 57111.html

Y por último, los conectores microUSB. Creo que cualquiera de estas 4 opciones nos vale, son más resistentes porque tienen 4 anclajes.

http://www.aliexpress.com/item/20-pcs-l ... 71516.html
http://www.aliexpress.com/item/20-pcs-l ... 67409.html
http://www.aliexpress.com/item/20PCS-lo ... 21241.html
http://www.aliexpress.com/item/20pcs-lo ... 30848.html

[mcleod_ideafix]

McLeod, viendo el mapa de memoria hay una cosa que me gustaría cambiar. Es la ubicación de la ROM del DivMMC, son 8K que creo que nos molestan. Mi sugerencia es pasarlos a BRAM y tener a nuestra disposición 128K contiguos para ROM de sistema.

¿¿Qué ROM del sistema para Spectrum necesita 128K??

Ya sé que si lo pasamos a BRAM perdemos flexibilidad a la hora de actualizar su contenido, pero es que tampoco es que haya muchas versiones de esa ROM y el hecho de que ocupe 8K en lugar de 16K lo hace menos manejable. Sé que la 250E tiene sólo 24K de BRAM, así que si necesitas más BRAM para otros menesteres (ULAplus) puedes quitársela a los 16K de boot donde va la BIOS.

Ahora mismo, y hasta que tu BIOS no esté completa, necesito arrancar con "algo" que me permita experimentar a gusto, cargando firmwares, con o sin DIVMMC, con o sin teclado issue 2, etc, y ese algo es una ROM de Spectrum, que ocupa 16K. La BRAM se usa no sólamente por la ROM de booteo, sino por el propio core T80 y por la paleta de la ULAplus.

Así tendríamos 8 bancos de ROM contiguos (128K) en los que poder implementar un superspectrum, necesitaríamos un tercer bit (además del bit 4 del 7ffd y del bit 2 del 1ffd) para direccionarlos.

Repito: ¿qué software usa eso? Es que no acabo de verlo. Moviendo la ROM del ESXDOS fuera tenemos, efectivamente 64KB extra. ¿Qué haces con esos 64KB extra? ¿Qué especificación de Spectrum la necesita? Si lo que quieres es poder cambiar de ROM... se supone que para eso están guardadas todas en la SPI Flash y cambias de una a otra durante el arranque.

Por otro lado tengo dudas a la hora de buscar 3 componentes...

A esto te contesto con más tranquilidad luego. Ahora tengo que salir.

[antoniovillena]

Buscando he encontrado este clon ruso:
http://en.wikipedia.org/wiki/ATM_(computer)

Pero la verdad es que no había pensado en nada. No sé, es que me parecen muy golosos esos casi 4 bancos vacíos contiguos. En el momento en que ocupas uno de esos bancos, aunque sea parcialmente, ya deja de ser potencia de 2 y se hace menos interesante. No obstante tienes razón, no veo que nadie vaya a utilizar a corto o medio plazo una ROM de 128K.

Evidentemente mientras no esté acabada la BIOS es mejor no reducir la boot ROM. Lo podemos tener en cuenta (lo de guardar la ROM de la DivMMC en BRAM) para más adelante por si le encontramos otra utilidad a esos 4 bancos de SRAM.

-- Actualizado 31 Mar 2014, 16:26 --

Por cierto he renombrado algunos componentes en el esquemático para que los valores de los componentes sean consecutivos y sea más fácil de montar. Por ejemplo R1 siempre tendrá un valor más pequeño o igual que R5. Aparte de esto no hay ningún otro cambio respecto al último esquemático.

[aowen]

Is there a reason not to load the ROMs on boot to the volatile RAM? I mean with esxDOS and mass storage I can't really see the point of going beyond the 256K of main RAM provided by the Chloe. And that's only required for supporting existing programs. A 48K machine with mass storage and random access (which esxDOS provides through its API) is much easier to use than a vast amount of paged RAM.

¿Hay alguna razón para no cargar la rom en el arranque en la RAM volátil (volatile). Quiero decir que con esxDOS y unidad de almacenamiento no veo la razón de ir más allá de los 256K de RAM principal que ya tiene el Chloe. Y éso solo es necesario para hacer funcionar programas ya existentes. Una máquina 48K con unidad de almacenamiento (esxDOS proporciona esto a través de su API) es mucho más fácil de usar que una gran cantidad de RAM paginada.

[TallerSeverino]

Is there a reason not to load the ROMs on boot to the volatile RAM? I mean with esxDOS and mass storage I can't really see the point of going beyond the 256K of main RAM provided by the Chloe. And that's only required for supporting existing programs. A 48K machine with mass storage and random access (which esxDOS provides through its API) is much easier to use than a vast amount of paged RAM.

Traduccion/translation:
¿Hay alguna razón para no cargar la rom en el arranque en la RAM volátil (volatile). Quiero decir que con esxDOS y unidad de almacenamiento no veo la razón de ir más allá de los 256K de RAM principal que ya tiene el Chloe. Y éso solo es necesario para hacer funcionar programas ya existentes. Una máquina 48K con unidad de almacenamiento (esxDOS proporciona esto a través de su API) es mucho más fácil de usar que una gran cantidad de RAM paginada.

[mcleod_ideafix]

Is there a reason not to load the ROMs on boot to the volatile RAM? I mean with esxDOS and mass storage I can't really see the point of going beyond the 256K of main RAM provided by the Chloe.

Todos los clones que se han hecho y que se parecen un poco en concepto al ZX-Uno hacen lo mismo: cargan la ROM en RAM y luego la mapean como sea necesario. Es más: teniendo en cuenta que la propia BIOS de Antonio podría cambiar, incluso con más frecuencia que ESXDOS, la pondría también (junto con la de ESXDOS y las demás), en la SPI Flash, y dejaría como ROM interna en el propio core una mini-ROM que cargara la BIOS de Antonio desde una posición fija de la SPI Flash, a un banco de la SRAM concreto, para botar la BIOS desde él. Si no lo he hecho ya es porque preferiría que el sistema botara lo más rápidamente posible, evitando más copias de la cuenta.
-------
All designed ZX Spectrum clones that share the same concept as ZX-Uno do the same: they load the ROM to RAM and then, they map it the way they need. I say more: having into account that probably, Antonio's BIOS will change more frequently than ESXDOS, I'd put it among ESXDOS ROM's and the rest of them, in the SPI Flash, and would leave as internal ROM a tiny stub whose work would be to load the BIOS from a fixed SPI location, to a fixed SRAM bank, and then boot from it. I haven't implemented this behaviour because my primary interest is the system to boot as fast as possible, avoiding as many SPI transactions as possible.