ZX-Uno

Estaba pensando en los juegos que se ejecutan desde ROM o en los modos all-RAM y los divides, tanto en el Spectrum real como en el ZX-Uno.

El divide (y el divmmc) "capturan" una serie de direcciones (NMI, carga, grabación) para poder cargar desde la SD. Si mal no recuerdo, las condiciones para que se cumpla son:
- Jumper "enabled" del divide activo.
- Acceso de lectura a la dirección correspondiente.
- M1 activada (es una ejecución de instrucción).

¿Se tiene en cuenta también el modo de paginación? Es decir ¿salta solo cuando la ROM está en su sitio o salta también cuando estás en el modo all-RAM de los +2A/+3 (p.ej.: modo 4,5,6,3)?

¿Existe la posibilidad de deshabilitar/habilitar temporalmente el divide o divmmc? Por ejemplo, deshabilitar las traps antes de poner un modo all-RAM y habilitarlas cuando necesites salir del modo all-RAM para usar la ROM? Entiendo que en el caso del ZX-Uno se podría usar MASTERCONF para deshabilitarlo pero ¿existe esta posibilidad en un divide/divmmc físico?

En el caso del ZX-Uno, se menciona que antes de habilitar divmmc hay que cargar el firmware en RAM. Si se deshabilita al vuelo y se vuelve a habilitar ¿sigue siendo necesario cargar el firmware o sigue en la RAM del ZX-Uno? Si sigue en la RAM... ¿se preserva también el estado (p.ej.: si hay un .tapeout activo?

El DivMMC no tiene en cuenta nada, se activa aunque esté el modo allram. La versión sintetizada se podría modificar para que tuviera en cuenta esas cosas pero el real, tal como está, no. Habría que hacer cambios en el la descripción de la CPLD, pero que yo sepa los fuentes no son públicos. En la web del autor solo esta el JED.

I need to write some allram code soon. What's the best way? Isolate the trapped addresses, and organise your routines so there is a gap there, and/or jump over the trapped addresses?

You can use that space to store data. These areas are only trapped when a instruction is fetched but it is safe to read/write them. Remember to set IM 2 before activating allram mode so RST $38 is not called.

En el DivMMC sintetizado del ZXUNO, cuando la máquina está en modo all-RAM (si mal no recuerdo), se desactivan los traps. De esa forma pude echar a andar el emulador de Pac Man de Simon Owen, que necesita uno de esos modos all-RAM

De todas formas, en la próxima release del core, sí que habrá una forma de quitar los traps estés donde estés.

Aprovecho que estamos hablando del DivMMC para ver is me puedes aclarar una cosa del funcionamiento...

Cuando se lee un dato del DivMMC, la CPU tiene el dato disponible mientras la señal /OE del módulo del divmmc está a 0 y esto ocurre cuando la CPU accede al puerto de lectura $3F o $EB, lo que dura la instrucción IN (bueno mientras /IORQ y /RD están a 0 y coincide la dirección del puerto).

Mientras se hace la lectura en sí, como puede tardar más de lo que dura la instrucción IN, se mantiene /WAIT a 0 para alargar la instrucción hasta que esté el dato disponible, ¿no? Así no falla la instrucción IN dure lo que dure y podemos usar /OE como señal para colocar en el bus de datos lo que llega desde el DivMMC. Y /WAIT se desactiva cuando se ha terminado de leer el dato del bus SPI, pero /OE se mantiene a 0 hasta que realmente la CPU lee el dato (continuando la instrucción IN) y por eso lee el dato correcto.

¿Es correcto?

PD: Espero que se me entienda que no me explico muy bien, lo se

Kyp escribió:¿Es correcto?

Mmmmmmmmmm.... no.

Cuando tú lees el registro de datos del DivMMC (el registro de datos SPI en realidad), tú no lees lo que te da la tarjeta SD. Tú en realidad lees la última cosa que puso la tarjeta SD en su última transferencia. Mientras lees eso, el maestro SPI realiza un ciclo de 8 pulsos de reloj a la tarjeta, pero ese ciclo terminará, probablemente, después de que el IN termine, así que es en el próximo IN donde leerás lo que la tarjeta acaba de transferir.

Por eso en el software, cuando se espera una respuesta de la tarjeta SD después de emitir un comando, hay que descartar el primer byte leído.

Te lo explican muy bien en la página web de quien diseño el cacharro en el que se basa el DivMMC: el ZXMMC. Mira:
http://www.probosci.de/zxbada/zxmmc/cpld.html

mcleod_ideafix escribió:

Kyp escribió:¿Es correcto?

Mmmmmmmmmm.... no.

Si ya sabía yo...

mcleod_ideafix escribió: Cuando tú lees el registro de datos del DivMMC (el registro de datos SPI en realidad), tú no lees lo que te da la tarjeta SD. Tú en realidad lees la última cosa que puso la tarjeta SD en su última transferencia. Mientras lees eso, el maestro SPI realiza un ciclo de 8 pulsos de reloj a la tarjeta, pero ese ciclo terminará, probablemente, después de que el IN termine, así que es en el próximo IN donde leerás lo que la tarjeta acaba de transferir.

Por eso en el software, cuando se espera una respuesta de la tarjeta SD después de emitir un comando, hay que descartar el primer byte leído.

Te lo explican muy bien en la página web de quien diseño el cacharro en el que se basa el DivMMC: el ZXMMC. Mira:
http://www.probosci.de/zxbada/zxmmc/cpld.html

¡Que interesante! Justo lo que necesitaba