Prueba de concepto de ultracarga a más de 150 kbps

[mcleod_ideafix]

Como ya adelanté a Inapetente en las news, me he decidido a echar un poquito de tiempo a un proyecto que tenía medio olvidado desde hace casi un año: es el tema de las ultracargas. La cosa surgió al querer alimentar la señal directamente a la ULA. Pensé que sería buena idea tener un puerto de entrada digital y no el sucedáneo que es la entrada EAR. Entonces caí en la cuenta de que muchos Spectrums tienen no una sino varias entradas digitales accesibles sin tener que desmontar el ordenador, y sin tener que construir hardware especial que haya que conectar al bus de expansión: los joysticks.

Si además hablamos de Spectrum +2, entonces ni siquiera hay que precouparse de enchufar nada al slot trasero. Afortunadamente, es muy probable que tu Spectrum tenga salida para joystick, bien "en placa madre" o en forma de Interface 2, Kempston, etc.

Así que la idea es que un sistema con microcontrolador lea un fichero desde una memoria SD y lo envíe al Spectrum vía el puerto de joystick.

Para esta demostración no hay memoria SD. Lo que he hecho es grabar dentro de la memoria del microcontrolador un juego entero, el Alchemist, con su pantalla de carga y todo. En total son 39680 bytes. Antes de darle paso al microcontrolador, se carga un pequeño programa BASIC con una rutina en C/M que es la que se encarga de leer el puerto de joystick, concretamente el puerto 2 del Interface 2. La rutina se carga de la forma habitual, en este caso, desde el propio PC con el Winamp. En el diseño final, será el propio microcontrolador quien también envíe la señal de carga estándar mediante una clavija conectada a EAR.

La técnica de carga es la siguiente: el puerto de joystick tiene 5 bits de datos, correspondientes a las 4 direcciones más el disparo. Nosotros usaremos 4 de esos bits (los correspondientes a las direcciones del mando) para codificar medio byte (un nibble), y el bit restante, como reloj para sincronizar la rutina de carga con el flujo de datos. Hacer la transmisión síncrona hace mucho más robusta la rutina de carga.

Aún así, para conseguir mayor velocidad, he mejorado el algoritmo de carga. El original enviaba al puerto de joystick un pulso alto por cada nibble, tardando 1 byte unos 80 microsegundos en transmitirse. El algoritmo mejorado envía nibbles en ambos flancos de la señal de reloj, remedando lo que hacen las memorias DDR (el algoritmo antiguo sería análogo al comportamiento de una memoria SDRAM). Esta mejora ha hecho un poco más crítica la temporización, pero se ha pasado de 80 a 50 microsegundos por byte enviado, dando un thoughput total de más de 150 kilobits/s.

[youtube]http://www.youtube.com/watch?v=GRCQqeoXn-k[/youtube]

[zyloj]

Espectacular. Ahora viene la pregunta obvia. ¿Los archivos que carga la rutina, son tzx, tap, o hay que generarlos con alguna utilidad extra?

Saludos

[Metalbrain]

¡¡¡Alucinante!!!

[mcleod_ideafix]

Espectacular. Ahora viene la pregunta obvia. ¿Los archivos que carga la rutina, son tzx, tap, o hay que generarlos con alguna utilidad extra?
Saludos

En esta demo, los bloques que carga en modo "ultra" son dos simples bloques de 6912 y 32768 bytes, respectivamente, que he metido "a mano" dentro de la memoria del microcontrolador (así me evito tener que usar la SD para esta demo). Los datos de a dónde debe ir cargado cada bloque los tiene la rutina que se carga al principio, como buen cargador que es.
El invento final no sé aún que formato usará: estoy entre usar TZX, que me permite mezclar carga estándar (para el cargador) con bloques de datos "puros" (que es lo que se carga en la parte "ultra"). En este caso, habría que generar esos TZX con alguna utilidad externa.
También había pensado en usar snapshots en formato Z80, o SNA, y que fuera el propio microcontrolador quien generara el cargador correspondiente según los datos del snapshot. Esta de hecho es la opción que usa k7zx.
Por supuesto, el invento final usaría una SD como soporte de memoria, y una pequeña pantalla LCD para poder navegar por los directorios, ficheros, etc. La idea es tener mi "pequeño" (no sé cuán pequeño sería capaz de fabricarlo) reproductor cuasi-instantáneo de snapshots para Spectrums reales.
Fíjate que la idea es extensible a cualquier otro micro que tenga puertos de joystick y un conector de audio para la carga estándar (MSX, Amstrad...). Bastaría con cambiar el firmware del microcontrolador.

[zyloj]

El invento final no sé aún que formato usará: estoy entre usar TZX, que me permite mezclar carga estándar (para el cargador) con bloques de datos "puros"
[...]
También había pensado en usar snapshots en formato Z80, o SNA

Obviamente, la ventaja de los TZX es que permitirían el acceso a juegos multicarga en el caso de que se modifique la rutina de carga interna del juego.

Fíjate que la idea es extensible a cualquier otro micro que tenga puertos de joystick y un conector de audio para la carga estándar (MSX, Amstrad...). Bastaría con cambiar el firmware del microcontrolador.

Otra idea bastante interesante.

Saludos

[mcleod_ideafix]

Obviamente, la ventaja de los TZX es que permitirían el acceso a juegos multicarga en el caso de que se modifique la rutina de carga interna del juego.

Cosa nada trivial, aún cuando la rutina de carga "ultra" no llega a los 60 bytes de longitud y es reubicable, dentro de los 32K superiores. Lo más práctico es generar las ultracargas a la manera que lo hace Inapetente en su k7zx, y soportar TZX tal y como lo he expuesto. Lo primero podrá usarse en snapshots que se tengan con antelación, y lo segundo, podrá usarse a medida que se fueran convirtiendo juegos de forma manual o automática a este formato.

[decicoder]

Ahora que ya tenía funcionando un versión reducida de k7zx para MSX y Amstrad este pedazo de invento lo deja obsoleto. Como me comentó ZxBruno hace tiempo en el foro de WOS "it's chuckie", vamos que tiene su guasa.

La cuestión de que tipo de ficheros utilizar en la tarjeta de memoria es interesante. Cuando empecé con el proyecto otla lo primero que se me ocurrió era utlizar ficheros snapshoots de los diferente sistemas como hacía con k7zx. Era utilizar la fuerza bruta pero lo más sencillo de programar.

A la hora de ponerme manos a la obra no fue tan sencillo. EL snapshot del amstrad gurda muchos registros de los puertos (del controlador de video por ejemplo) por lo que primero habría que restaurar el estado de todos estos registros cargando un primer bloque y ejecutándolo y luego cargar la memoria. EN MSX ni siquiera tengo claro que exista el concepto de fichero .snapshot standard.

Pero en msx resultó fácil construir bloques para cargar. Los ficheros .rom .dsk típicos de msx se procesan con herramientas ya hechas que extraen ficheros .bin que tienen información necesaria para cargarse: inicio, longitud y direccion de ejecución.

Algo parecido se podría hacer para los ficheros .tap .tzx .sna .z80 y. .dsk. Convertirlos a una especie de churro de bloques en un único fichero fácil de interpretar por el microcontrolador y a la vez compatible para cargarlo por un dispositivo de audio.

Sugiero un formato algo así

Cabecera
-Nombre de máquina (zx48k, cpc464 , msx1)
-nombre.tipo del fichero origen .tap.tzx.cdt.dsk.sna.z80.rom
-nombre que se verá en el sistema (program: )
-parametros varios antes de empezar la carga (CLEAR ...)
-numero de bloques que tiene este fichero

N Bloques cada bloque con una cabecera de bloque y los datos

CAbecera de bloque
-indice del bloque
-nombre de bloque
-inicio
-longitud (con bloques de longitud = 0 se podría jugar con pausas , paradas , etc)
-direccion de ejecución.
-informacion de la paginacion de memoria donde va el bloque
-tipo de bloque (patalla, basic , etc)
-checksum del bloque de datos
-bloque de datos

Contra esta propuesta se admiten todo tipo críticas, tanto las constructivas como las destructivas.

[Gandulf]

Esto es un poco offtopic pero al ver la firma de decicoder me ha entrado la duda:

¿Qué utilidad tiene escribir cosas en el registro R con la instrucción ld r, a? Leerlo la puede tener por ejemplo para obtener de forma sencilla un valor aleatorio de byte, pero escribirlo así de repente no veo para que puede servir. Seguramente tiene alguna explicación relacionada con el hardware. ¿Alguien lo puede explicar brevemente?

[Digital Prawn]

Hola!

Le ruego me disculpe por mis errores. Mi español es muy básico. (Estoy utilizando el babelfish)

7 mordidos del registro de ' r ' se preserva siempre, y se pueden utilizar como bandera.

Saludos,

DP

[Gandulf]

Mordido = bit, en español decimos bits también, no se traduce

7 bits se preservan?? no puede ser. Creo que lo que pasa es que se preserva el bit más alto. El bit 7 o valor 128. Que los que sepan más del registro R y el refresco de la RAM nos cuenten, pero creo que es eso, que se puede usar el bit de mayor peso como flag.

Gracias por la pista

[Digital Prawn]

Gracias, signifiqué se preserva el bit más alto (b7),

DP

[zxbruno]

Como me comentó ZxBruno hace tiempo en el foro de WOS "it's chuckie", vamos que tiene su guasa.

lol

Creo que te refieres a este post:

http://www.worldofspectrum.org/forums/s ... ostcount=5

'Chuckles' (no 'Chuckie' ) significa 'reírse con satisfacción'

[decicoder]

Creo que te refieres a este post:

http://www.worldofspectrum.org/forums/s ... ostcount=5

'Chuckles' (no 'Chuckie' ) significa 'reírse con satisfacción'

Sí, me obligaste a ir al diccionario. Y entendí el signifcado con el matiz de sonrisa de resignación del que acepta con humor los caprichos del destino sobre las futiles existencias humanas.

(Estoy utilizando el babelfish)

7 mordidos del registro de ' r ' se preserva siempre, y se pueden utilizar como bandera.

XDDDD , que risa el babelfish. Esto me recuerda un chiste de los Bocabits , los snacks de Matutano.
-¿que es lo que hacen ocho Bocabits?
-Pues un Bocabyte.

¿Qué utilidad tiene escribir cosas en el registro R con la instrucción ld r, a?
¿Alguien lo puede explicar brevemente?

Utilizo el registro R como contador. El registro R se incrementa en uno , o dos, por cada instruccion ejecutada por el Z80.
XOR A - LD R,A pone a cero el contador.
Se entra en un bucle sin fin ( IN F,(C) - JP PE,bu) hasta que haya un cambio esperado en el puerto. A cada vuelta del bucle el registro R se incrementa en 3 (2+1).
A la salida de bucle retomamos el valor de R (LD A,R) y dividiéndolo por tres sabemos el número de vueltas que dio el bucle.

[Digital Prawn]

XDDDD , que risa el babelfish. Esto me recuerda un chiste de los Bocabits , los snacks de Matutano.
-¿que es lo que hacen ocho Bocabits?
-Pues un Bocabyte.

Usted tiene razón sobre ése.

Puedo utilizar el babelfish para traducir de español al inglés, porque soy una persona de habla inglesa nativa.

Pero no debo utilizarlo para traducir de inglés a español (porque no puedo ver los errores).

Gozo de este foro, así pues, aprendo más palabras del español cada día.

Deseo escribir más a menudo, pero tengo aún así más a aprender.

Para ahora, es más fácil leer que escribir.

Saludos

[Gandulf]

A la salida de bucle retomamos el valor de R (LD A,R) y dividiéndolo por tres sabemos el número de vueltas que dio el bucle

Pero esto es así sólo si el bucle no se ejecuta más de 42 veces, si no me equivoco; en el caso de que ese bit 7 no se mantenga constante (85 en caso de que use los 8 bits). Al llegar al valor máximo vuelve a 0 y entonces ya habremos perdido la cuenta. Imagino que para la rutina de carga es algo que no se dará nunca.