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

Si por algo se caracteriza el Spectrum es por su gran variedad de periféricos (clásicos y modernos)

Moderador: Sir Cilve Sinclair

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3984
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

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

Mensaje por mcleod_ideafix » Jue Sep 27, 2007 11:34 pm

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]
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
zyloj
Freddy Hardest
Mensajes: 711
Registrado: Mar Abr 17, 2007 12:31 am
Ubicación: cada día más lejos de aquí
Contactar:

Mensaje por zyloj » Jue Sep 27, 2007 11:55 pm

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

Saludos

Avatar de Usuario
Metalbrain
Freddy Hardest
Mensajes: 590
Registrado: Lun May 07, 2007 8:17 am
Ubicación: Sevilla
Contactar:

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

Mensaje por Metalbrain » Jue Sep 27, 2007 11:58 pm

:shock:

¡¡¡Alucinante!!!

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3984
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Mensaje por mcleod_ideafix » Vie Sep 28, 2007 12:04 am

zyloj escribió: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.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
zyloj
Freddy Hardest
Mensajes: 711
Registrado: Mar Abr 17, 2007 12:31 am
Ubicación: cada día más lejos de aquí
Contactar:

Mensaje por zyloj » Vie Sep 28, 2007 12:53 am

mcleod_ideafix escribió: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.

mcleod_ideafix escribió: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

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3984
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Mensaje por mcleod_ideafix » Vie Sep 28, 2007 1:00 am

zyloj escribió: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.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
decicoder
Jack The Nipper
Mensajes: 176
Registrado: Jue Jul 19, 2007 10:37 am

Mensaje por decicoder » Sab Sep 29, 2007 9:41 am

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.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

Gandulf
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Sab Sep 29, 2007 12:03 pm

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?
Un saludo,

Gandulf

Avatar de Usuario
Digital Prawn
rst 0
Mensajes: 32
Registrado: Sab Sep 29, 2007 12:36 am
Ubicación: Birkenhead, Inglaterra
Contactar:

Mensaje por Digital Prawn » Sab Sep 29, 2007 1:01 pm

Hola!

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

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

Saludos,

DP

Gandulf
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Sab Sep 29, 2007 1:05 pm

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

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 :)
Última edición por Gandulf el Lun Oct 01, 2007 6:23 am, editado 1 vez en total.
Un saludo,

Gandulf

Avatar de Usuario
Digital Prawn
rst 0
Mensajes: 32
Registrado: Sab Sep 29, 2007 12:36 am
Ubicación: Birkenhead, Inglaterra
Contactar:

Mensaje por Digital Prawn » Sab Sep 29, 2007 1:22 pm

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

DP

Avatar de Usuario
zxbruno
Freddy Hardest
Mensajes: 585
Registrado: Dom Jun 03, 2007 3:28 am
Ubicación: Anaheim, California, USA

Mensaje por zxbruno » Sab Sep 29, 2007 9:48 pm

decicoder escribió: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' :D

Avatar de Usuario
decicoder
Jack The Nipper
Mensajes: 176
Registrado: Jue Jul 19, 2007 10:37 am

Mensaje por decicoder » Dom Sep 30, 2007 8:13 pm

zxbruno escribió:Creo que te refieres a este post:

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

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


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.

Digital Prawn escribió: (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.

Gandulf escribió:¿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.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

Avatar de Usuario
Digital Prawn
rst 0
Mensajes: 32
Registrado: Sab Sep 29, 2007 12:36 am
Ubicación: Birkenhead, Inglaterra
Contactar:

Mensaje por Digital Prawn » Dom Sep 30, 2007 10:39 pm

decicoder escribió: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. :lol:

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
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Lun Oct 01, 2007 6:22 am

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.
Un saludo,

Gandulf

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: Google [Bot] y 9 invitados