k7zx se integra en el proyecto otla.

Todo sobre la creación, diseño y programación de nuevo software para
nuestro Spectrum

Moderador: Sir Cilve Sinclair

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

k7zx se integra en el proyecto otla.

Mensaje por decicoder » Sab Feb 23, 2008 10:27 am

Otla 2.0 ya está disponible.
http://code.google.com/p/otla/

También se puede descargar k7zx 4.3 que admite los ficheros .sbb creados por OtlaBuilder.

Con OtlaBuilder se podrán convertir ficheros tap y tzx que antes no se podían cuando faltaba información de la cabecera de los bytes. (Aunque no es trivial porque habrá que averiguar las direcciones de incio y ejecución de los bloques).
También se pueden hacer cosas más complicadas. Como cargar una pantalla de presentación (fichero .scr) antes de la carga de un snapshot.

Con más paciencia incluso se podrían convertir juegos multicarga

Nota para el admistrador: Los zip disponibles en las descargas incluyen ejemplos de juegos de Spectrum, CPC y MSX. Entiendo que todos ellos son de libre distribución aunque no tnego autorización expresa. Espero que no haya ningún problema.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

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:

Re: k7zx se integra en el proyecto otla.

Mensaje por zyloj » Sab Feb 23, 2008 11:01 am

Si te puede servir, puedes incluir como ejemplos los juegos de Compiler software. Con esos no tendrás problemas de tener que mirar si hay permisos de distribución. ;)

Saludos

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

Re: k7zx se integra en el proyecto otla.

Mensaje por decicoder » Mié Feb 27, 2008 7:35 pm

zyloj escribió:Si te puede servir, puedes incluir como ejemplos los juegos de Compiler software. Con esos no tendrás problemas de tener que mirar si hay permisos de distribución. ;)


Mejor que eso. He preparado un pack con los juegos de Compiler Software convertidos al formato .SBB.

http://personal.auna.com/casariche/otla ... e_pack.zip

A proposito del formato .SBB. ¿Podría ser compatible con un dispositivo como el divIDE? Puede que no tenga mucha utilidad salvo quizá en juegos multicarga
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

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

Re: k7zx se integra en el proyecto otla.

Mensaje por decicoder » Jue Mar 20, 2008 11:36 am

Hay una nueva versión del proyecto otla.

Corrige algunos bugs. Y tiene una novedad- A la hora de reproducir el wav se puede controlar el volumen directamente y tambien se puede elegir en que tarjeta de sonido se quiere reproducir (suponienod que haya más de una).

Quiere decir que se puede rescatar una tarjeta de sonido guarripeich de esas que se pueden encontrar en restrillos por un euro y añadirla al PC. Así la tarjeta prinicpal seguirá funcionando según su misión de reproducir sonido y no habrá que desconectar y conectar cables.

Más que una tarjeta de sonido habremos añadido al PC una tarjeta de red para ordenadores de 8 bits.

Se puede hacer este experimento curioso.

Habrimos un emulador que permita "Load fron Audio Source" como en Spectaculator 5.3.
La salida de audio de la tarjeta que hemos añadido al sistema la enchufamos al Linea In de la tarjeta por defecto (que utlizará el Spectaculator) tecleamos Load "" en el emulador y hacemos Click en el OtlaPlayer para reproducir el wav por la tarjeta añadida.

El Spectaculator carga de la señal de audio real. la parte de velocidad normal sin problemas. Pero la parte de alta velocidad fallará. ¿por que? En un spectrum real se muestrea fisicamente la entrada Ear a 130 kHz y el emulador tiene que conformarse con la que le dé la tarjeta de sonido.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

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

Re: k7zx se integra en el proyecto otla.

Mensaje por mcleod_ideafix » Jue Mar 20, 2008 3:40 pm

decicoder escribió:El Spectaculator carga de la señal de audio real. la parte de velocidad normal sin problemas. Pero la parte de alta velocidad fallará. ¿por que? En un spectrum real se muestrea fisicamente la entrada Ear a 130 kHz y el emulador tiene que conformarse con la que le dé la tarjeta de sonido.


A ver... esto no lo acabo de entender. Lo primero, ¿por qué un Spectrum real muestrea a 130 kHz, cuando la señal de audio tiene un espectro mucho más reducido?
Lo segundo: eso de que "el emulador tiene que conformarse..." ¿Acaso no debe también conformarse el Spectrum real con la misma señal? Quiero decir: que si un Spectrum real esto funciona, el Spectaculator, suponiendo que pueda con esos 130 kHz de muestreo de la señal, también debería poder.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: k7zx se integra en el proyecto otla.

Mensaje por na_th_an » Jue Mar 20, 2008 8:46 pm

Creo que se refiere a que las tarjetas de sonido actuales, como mucho, funcionan a 96kHz. Esto significa que un emulador podrá muestrear como máximo a esa frecuencia.

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

Re: k7zx se integra en el proyecto otla.

Mensaje por mcleod_ideafix » Jue Mar 20, 2008 10:24 pm

na_th_an escribió:Creo que se refiere a que las tarjetas de sonido actuales, como mucho, funcionan a 96kHz. Esto significa que un emulador podrá muestrear como máximo a esa frecuencia.

Aun así sigo sin verlo. A ver, tenemos una tarjeta de sonido que reproduce el WAV, se alimenta con ese WAV a un Spectrum físico y carga. No es así? Ese WAV como mucho a cúanto está reproduciendo? a ¿48 kHz? ¿96 kHz? ¿Cuál es el ancho de banda efectivo de la señal, teniendo en cuenta que después de la conversión D/A hay filtros y demás historias? Intuyo que como mucho, tendrás una señal de 20 a 24000 Hz a la salida.

A esa frecuencia un pulso alto o bajo dura como mínimo 20 microsegundos. Un Spectrum real, "escuchando" ese WAV y muestreándolo a 130 kHz con 1 bit de resolución "leerá", dentro de ese pulso, 3 valores iguales (dicho de otra forma, ese pulso mínimo que entrega la fuente de audio es visto hasta tres veces consecutivas por el Spectrum).

Si en lugar de ser un Spectrum real es un programa de ordenador que emula el bit de EAR del Spectrum a través de lo que le envía una tarjeta de sonido, pues bien, vale que esa tarjeta cogerá y podrá, como mucho, enviarle al emulador un número diferente cada 1/96000 segundos (sup. eso, 96 kHz de frecuencia de muestreo). Como la señal tiene un ancho de banda mucho menor (como debe ser, para evitar aliasing y todo eso), resulta que ese número diferente resulta que sólo lo es "a tramos", es decir, que durante 3 o 4 muestras el valor no cambia, porque la señal de audio varía lentamente respecto a la frecuencia con la que es leída.

El programa demandará números a la velocidad que pueda, en el peor de los casos, limitado por la velocidad del procesador donde se ejecute, no limitado por la tarjeta de sonido. Si la tarjeta de sonido no puede enviarle números diferentes a esa cadencia, tiene dos opciones: darle el mismo número siempre que lo pida, hasta que éste cambie por una nueva muestra, o bien interpolar y darle un número basado en los valores de las 2 o 3 últimas muestras (oversampling). Ambas opciones pueden implementarse por software, así que nuestro emulador no tiene excusa. De todas formas...¿qué ventaja tiene el muestrear una señal en el Spectrum más veces de las que se sabe que va a cambiar? ¿Redundancia en la medida para minimizar errores de carga? Vale, bien, pero eso también funciona con el emulador.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: k7zx se integra en el proyecto otla.

Mensaje por na_th_an » Vie Mar 21, 2008 12:09 am

Había entendido mal. Pensaba que se hablaba de una fuente externa alimentando a un Speccy y a un emulador, que funcionase en el Speccy y no en el emulador. Releyendo, veo que estaba equivocado :)

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

Re: k7zx se integra en el proyecto otla.

Mensaje por mcleod_ideafix » Vie Mar 21, 2008 12:56 am

Ahmmmm... no, es precisamente eso. Una fuente externa (una tarjeta de sonido) que alimenta por una parte a un Spectrum real, y por otra parte a Spectaculator, a base de usar OTRA tarjeta de sonido y uniendo el LINE OUT de la primera con el LINE IN de la segunda.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: k7zx se integra en el proyecto otla.

Mensaje por na_th_an » Vie Mar 21, 2008 3:03 am

Exacto. En ese caso, me planteo la misma duda que tú.

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

Re: k7zx se integra en el proyecto otla.

Mensaje por decicoder » Vie Mar 21, 2008 11:49 am

Al final acabamos la casa por los cimientos. Por la teoría. Que la carga a alta velocidad funcione en la práctica es una gran satisfación pero entender porqué tienen un límite y llegar a saber cual es demostrándolo matemáticamente lo sería todavía más.
Tengo algunas hipotesis que pueden ser equivocadas. Las expongo para el debate.

El experimento exactamente es este.

La tarjeta por defecto del sistema: una SoundBlaster supuestamente con una frequencia nativa de 44100 Hz. Será la que utiliza Spectaculator 5.3 para recibir la señal

Tarjeta adicional: una Yamaha supuestaente con una frecuencia nativa de 48000 Hz.

Señal de text. Una wav a 44100 Hz , 3,5 samples/bit y forma de onda cúbica. Es decir la maxima frecuencia que se va trasmitir será de 11 KHz y la minima diferencia de duracion del periodos entre dos simbolos diferentes es de solo dos muestras
(En lugar medir el tiempo en segundos mejor hablaremos de muestras en el wav o de Tsates de Spectrum 1 muestra = 79,4 Tstates)

Esto funciona perfectamente en un Spectrum real. En el emulador se ve esto:

Imagen


En la pantalla de distinguen 12 cuadrados cada uno de ellos con 4092 pixels. Mas o menos a ojo de buen cubero se ven unos 20 errores por cuadrado. como se trasmiten dos pixels en cada ciclo la tasa de error es mas o menos 1%.

Primera explicación: que el emulador tenga algún bug para tratar directamente la señal. Si en lugar del emulador abrimos la Grabadora de Sonido y grabamos con la SB el sonido que sale de la Yamaha en un fichero wav. Posteriormente ese fichero lo abrimos con el emulador para cargarlo se observa lo mismo. El emulador va bien.

Segunda explicación: Que la SB tenga un conversor A/D peor que el que tiene el spectrum. Dudoso.

Tercera explicacion: El Spectrum muestra la realidad analógica con mayor frecuencia que la tarjeta de sonido.

¿Con una frecuencia de muestreo de 44100 bastaría para muestrear una señal que fue construida digitalmente también a 44100?

Suponiendo que emisor y receptor muestreasen exactamente a la misma frecuencia y que el receptor estuviese muestreando justo en el instante intermedio entre los instantes de dos muestras del emisor sería factible.
¿Pero que pasa si el receptor no está sintonizado en la fase más favorable y se pone a muestrear justo cuando el emisor está haciendo una transición?
¿Y si emisor y receptor no están exactamente en la misma frequencia?

Esta claro que no se puede hacer un bucle de 79,4 states. Ademas el +2 tiene otra freceuncia de reloj con lo que la cosa se complica todavía más

Por eso cuanto mayor sea la frecuencia de muestreo mejor. (1)


Cuando digo que el Spectrum muestrea a 130kHz no es del todo exacto. Se muestrea según este bucle.

bu:
INC HL ; 6
in a,(c) ; 12
jp pe, bu ; 10
; total 28 tStates

La frecuncia del reloj son 3,5 MHz luego la frecuecia de muestreo sería 125 KHz (con la instruccion INC L en lugar de INC HL serían 134 KHz).
Y esto tampoco es exacto: la instruccion IN A,(C) no dura siempre 12tStates. Por efecto de la memoria contenida puede durar 12 o hasta 18.

Curiosamente el bucle más lento con INC HL funciona un poco mejor que con INC L (en contradicción con afirmación (1)) ¿Por qué? Quizá por que el error maximo de la memoria contenida es proporcialmente menor 6/28 = 21% frente a 6/26=23%


Según leí en algún docuemnto se puede considerar que la duracion media de la instrucción in a,(c) es de 14,3 tStates.

La duracion de media del bucle sería 30,4 tStates que darían para en el tiempo que dura un sample del wav muestrear el puerto 2,6 veces. Pues eso no es suficiente para distinguir sin errores un ciclo que dura 4 samples de otro de 5 samples.

Pero ojo al dato. Un amstrad y un MSX sí. Un MSX puede carga a 2,25 samples/bit con este bucle. Para hacer lo mismo con un Spectrum hay que ir a bucles más rápidos.

¿O quizá todavía más lentos para compensar más el error de la memoria contenida? Habría que probarlo.

Pero aumentando el tiempo del bucle nos podríamos topar con el Teorema de la Conservación del Sincronismo:

Sea Ts el tiempo más breve de un ciclo para la trasmision de un simbolo. Para muy alta velocidad 79,4*2 = 178,8 tStates

Sea To el tiempo de todas las operaciones necesarios para decodificar y procesar un simbolo en la rutina de carga

Sea Tb el tiempo del bucle de detecion del flanco de subida que es igual al tiempo del bucle de detencion de flanco de bajada.

Entonces . para que la rutina de carga no pierda el sincronismo se debe cumplir:

To+3*Tb < Ts

Puede que 3 sea demasiado conservador pera la constante estará entre 2,5 y 3


Si se aumenta Tb se tiene menos tiempo para hacer las operaciones de recibir el dato , guardarlo en memoria, cambiar el color del borde, comprobar el fin de trasmisión ...


Con este experimeto de las dos tarjetas se puede ver en emulador algo que solo se demostraba en un Spectrum real. El difente comportameinto de según la forma de onda elegida. ¿Por qué? Eso merece un estudio a parte.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

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

Re: k7zx se integra en el proyecto otla.

Mensaje por mcleod_ideafix » Vie Mar 21, 2008 3:54 pm

decicoder escribió:Primera explicación: que el emulador tenga algún bug para tratar directamente la señal. Si en lugar del emulador abrimos la Grabadora de Sonido y grabamos con la SB el sonido que sale de la Yamaha en un fichero wav. Posteriormente ese fichero lo abrimos con el emulador para cargarlo se observa lo mismo. El emulador va bien.

¿Y si alimentas el WAV original (el creado con la herramienta) al Spectaculator? ¿Lo coge bien o con errores?

decicoder escribió:Segunda explicación: Que la SB tenga un conversor A/D peor que el que tiene el spectrum. Dudoso.

No, pero el conversor A/D de la tarjeta tiene algo que el del Spectrum no tiene: un filtro potente para el aliasing. La señal con la que estás alimentando a ese conversor es cuadrada: tiene muchos armónicos que están más allá de la frecuencia de 44100 Hz. Como esa señal se creó artificialmente y no como resultado de un muestreo de una señal real, puede tenerlos. Cuando esa señal cuadrada se envía a la segunda tarjeta de sonido "conectada" al Spectaculator, sus filtros de aliasing la redondean, eliminando los cambios bruscos de nivel y por tanto, introduciendo errores en lo que Spectaculator considera nivel alto o nivel bajo. Dado que la diferencia entre un 1 y un 0 es sólo 1 sample... creo que tengo claro qué pasa: el filtro de entrada de la segunda tarjeta de sonido puede hacer que ese sample tenga un nivel que no le corresponde, con lo que es interpretado erróneamente.
Para demostrar que esto puede ser así, no hay más que coger el WAV original y el WAV remuestreado y compararlos.

decicoder escribió:¿Con una frecuencia de muestreo de 44100 bastaría para muestrear una señal que fue construida digitalmente también a 44100?

Ahí está la cosa: que el WAV original es una señal cuadrada. Para que una tarjeta de sonido obtuviera un WAV como el que vuestra herramienta genera, a partir de una fuente de sonido analógica, tendría que haber muestreado a mucha más frecuencia que 44100 Hz. ¿Cuánta más? Veamos:

Una señal cuadrada puede aproximarse por varias sinusoides (sus armónicos) de frecuencias cada vez más altas. Un armónico es una señal cuya frecuencia es múltiplo de la fundamental.
Concretamente, la señal cuadrada es la suma de una sinusoide de frecuencia igual a la fundamental, más una sinusoide de frecuencia 3 veces la fundamental, más una con 5 veces la fundamental, más una con 7, etc... Es decir, la suma de los armónicos impares. Por supuesto, cuanto mayor es el armónico, menos potencia entrega a la señal final.
En la figura se ve la reconstrucción de una señal cuadrada con 1 armónico (k=1), 3 armónicos (k=1,3,5), 6 armónicos (k=1,3,5,7,9,11), etc...
Imagen

Según comentas, las señales que hay en el WAV original tienen 4 samples o 5 samples (supongo que una de las señales es para codificar un 0 y la otra un 1). Suponiendo una señal cuadrada de 4 samples por semiperíodo (4 samples arriba, 4 abajo, y así sucesivamente) tendríamos una frecuencia fundamental de 5,51 kHz (primer armónico). Sus siguientes armónicos estarían por tanto en las frecuencias 16,5 kHz, 27,5 kHz, 38,6 kHz,...

Dado que la tarjeta de sonido tiene filtro a la entrada, se "cargará" todos los armónicos por encima de 20 kHz. Eso nos deja con solo ¡dos armónicos! el 1 y el 3. La señal que "ve" la segunda tarjeta de sonido resulta que es peor que la primera que sale en el dibujo.

Se puede observar que harían falta al menos 6 armónicos para obtener algo parecido a una señal cuadrada (a ojo, según el dibujo), y quizás me quede corto. El sexto armónico tiene una frecuencia 11 veces la fundamental. Se puede medir el error RMS derivado de dejar de tomar a partir de cierto número de armónicos para reconstruir la señal. Tendríamos esto:
Imagen

El error decae con lentitud, tanto es así que para tener un nivel de error como el marcado por el pequeño asterisco a la derecha de la segunda gráfica, harían falta 99 armónicos. Spectaculator "ve" una señal con un error aproximadamente de 0,3 . Una señal cuadrada reconstruida así tiene los flancos muy poco definidos, y provocará errores de medida, si como es el caso, dichas medidas deben discernir 22 us (1 sample) para decidir si es un 1 o un 0.

decicoder escribió:Por eso cuanto mayor sea la frecuencia de muestreo mejor.

Efectivamente. Es que con 44100 Hz nos quedamos muuuy cortos. Habría que digitalizar a ¡¡1 MHz!! para obtener una señal como la original.

decicoder escribió:Entonces . para que la rutina de carga no pierda el sincronismo se debe cumplir:

To+3*Tb < Ts

Puede que 3 sea demasiado conservador pera la constante estará entre 2,5 y 3

En mi rutina de carga por joystick creo que hice esa constante = 2. Eso si he entendido bien el papel de esa constante (número de vueltas que debe dar como mínimo el bucle de detección de flanco).

Puede que te preguntes...según esto, ¿cómo es que obtengo errores, pero son pocos? Con una señal tan pobre en armónicos deberían haber ocurrido más errores, y sin embargo la pantalla que pones como ejemplo es bastante visible. Esto tiene que ver con el nivel de tensión que debe tener la señal para que la ULA lo considere un 1 o un 0. En el Spectrum real son 0,7 voltios, pero seguramente Spectaculator simplificará e interpretará un 1 cuando la señal es positiva, y 0 cuando es negativa: discernir el nivel lógico así tiene su ventaja, y es que todos los armónicos se "encuentran" (tienen el mismo nivel) precisamente en los mismos puntos donde la señal que corresponde a la frecuencia fundamental cambia de signo. Es decir, es el punto donde más pendiente tiene.
En un Spectrum real, alimentado con esta segunda señal, es posible que te encuentres aún más errores, ya que discierne un poco por encima de esos 0 voltios, donde la señal no es ya tan rápida (su pendiente es menor).
Web: ZX Projects | Twitter: @zxprojects

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

Re: k7zx se integra en el proyecto otla.

Mensaje por decicoder » Vie Mar 21, 2008 7:23 pm

mcleod_ideafix escribió:¿Y si alimentas el WAV original (el creado con la herramienta) al Spectaculator? ¿Lo coge bien o con errores?

Claro, eso siempre. Si no, hubiese imposible depurar el código.
Cuando el Speculator coge el Wav, señal virtual perfecta, funciona hasta 38.400 bps. Incluso más con frecuencias de muestreo que nunca vas a encontrar en la realidad como 52 kHz
mcleod_ideafix escribió:No, pero el conversor A/D de la tarjeta tiene algo que el del Spectrum no tiene: un filtro potente para el aliasing. La señal con la que estás alimentando a ese conversor es cuadrada: tiene muchos armónicos que están más allá de la frecuencia de 44100 Hz.


No, es una onda muy parecida a la senoidal. Forma de onda cubica. Bien es cierto que para ver una forma de onda "suave" en un ciclo de sólo 4 sambles requiere un poco de imaginación. Pero para 10 samples (que es el ciclo mas largo para el simbolo 11, los cuadrados negros) también hay errores. Y más o menos los mismos que la frecuencia más altas (cuadrados blancos , simbolo 00)
mcleod_ideafix escribió:Cuando esa señal cuadrada se envía a la segunda tarjeta de sonido "conectada" al Spectaculator, sus filtros de aliasing la redondean, eliminando los cambios bruscos de nivel y por tanto, introduciendo errores en lo que Spectaculator considera nivel alto o nivel bajo. Dado que la diferencia entre un 1 y un 0 es sólo 1 sample..


Efectivamente ese es el probelma . Y eso que la diferencia entre un simbolo 00 y un simbolo 01 es un poco más generosa 2 samples. Con una tarjeta de sonido que muestrease más rápido se solucianría el probelama (pero el maximo como bien dice na_th_an es 96 kHz). Claro que si el Emulador no utiliza la potencia de la tarjeta y muestrea por software a 44100 tendrá el mismo problema

mcleod_ideafix escribió:Dado que la tarjeta de sonido tiene filtro a la entrada, se "cargará" todos los armónicos por encima de 20 kHz. Eso nos deja con solo ¡dos armónicos! el 1 y el 3. La señal que "ve" la segunda tarjeta de sonido resulta que es peor que la primera que sale en el dibujo.


Pero eso es tambien lo que ve el espectrum (si no peor).
1º la tarjeta de sonido de salida tambien filtros con frecuencia de corte de 20kHz
2º la entrada Ear tambien tiene un condensador en paralelo.

Como consecuencia los flancos no son verticales (el ideal de la onda cuadrada) pero da igual. Lo que importa es que la deteccion del flanco se haga con un error razonable (¿menos del 50% de 79,4 tStates ?)

mcleod_ideafix escribió:Esto tiene que ver con el nivel de tensión que debe tener la señal para que la ULA lo considere un 1 o un 0. En el Spectrum real son 0,7 voltios, pero seguramente Spectaculator simplificará e interpretará un 1 cuando la señal es positiva, y 0 cuando es negativa: discernir el nivel lógico así tiene su ventaja, y es que todos los armónicos se "encuentran" (tienen el mismo nivel) precisamente en los mismos puntos donde la señal que corresponde a la frecuencia fundamental cambia de signo. Es decir, es el punto donde más pendiente tiene.


la deteccion del flanco es teoricamente cuando la señal pasa de positiva a negativa. Y para el Spectrum debería ser lo mismo aunque sea más imperfecto por el "offset" de 0,7. Si la onda fuese cuadrada con un flanco ideal vertical daría lo mismo.
Interesa que el flanco sea lo más vertical posible. Y en el caso del metdo que nos ocupa que le flanco de bajada sea lo más vertical posible, el de subida da lo mismo no es tan importante. Por eso la forma de onda cubica es la mejor (conjetura)

mcleod_ideafix escribió:En un Spectrum real, alimentado con esta segunda señal, es posible que te encuentres aún más errores, ya que discierne un poco por encima de esos 0 voltios, donde la señal no es ya tan rápida (su pendiente es menor).


Obviamente , si un wav no funciona en emualdor tampoco va a funcionar en el Spectrum Real. Mmm o quizá sí; o quizá con menos errores porque los compoentes analogicos "suavizan" la onda y el Spectrum Real sigue trabajando a 125 KHz. No me atrevería a apostar.

En cualquier caso como conclusión : un emulador nunca podrá emular a Spectrum Real en la funcion cargas de alta velocidad con entrada de una señal real externa.

Y esto me lleva otra conclusion respecto al siguiente paso. La rutina de grabación a alta velocidad.

Un Spectrum (o máquina de 8 bits) podrá trasmitir mediante una señal de audio a otro Spectrum a más velocidad de la que podrá trasmitir a un PC.
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

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

Re: k7zx se integra en el proyecto otla.

Mensaje por mcleod_ideafix » Vie Mar 21, 2008 8:19 pm

decicoder escribió:Un Spectrum (o máquina de 8 bits) podrá trasmitir mediante una señal de audio a otro Spectrum a más velocidad de la que podrá trasmitir a un PC.

Sí, a no ser que esa señal se transmita, pongamosssssssss, a un bit del puerto paralelo.
Además, ya Sinclair se percató de ello. La ZX-Net del Interface 1 no es más que un "EAR" y un "MIC" al que le han quitado todo tipo de filtros: usa un protocolo muy similar al RS232 para transmitir bytes: el receptor se sincroniza con el emisor a nivel de byte, no a nivel de bit. La velocidad efectiva, tal como la pude medir hace meses, es de unos 35 kbps.
De hecho mi primera ultracarga no fue por el puerto de joystick, sino por el puerto de entrada de la ULA, pero con truco... metiendo la señal directamente a la ULA, saltándome el filtro de entrada de EAR. Emulando el mismo protocolo que la ZX-Net conseguí más o menos eso, poco más de 30 kbps cargando.
Web: ZX Projects | Twitter: @zxprojects

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

Re: k7zx se integra en el proyecto otla.

Mensaje por decicoder » Sab Mar 22, 2008 1:00 pm

mcleod_ideafix escribió:Sí, a no ser que esa señal se transmita, pongamosssssssss, a un bit del puerto paralelo.


Sí pero habría que poner algun tipo de adaptador de la sañel alterna del audio. Sería una opcion para los emuladores. Tomar un bit del puerto paralelo como EAR.

Se me ocurre ahora otra solucion más simple. El emulador (0 programa de PC que quiera recibir datos de un Spectrum a alta velocidad) tiene una señal muestreada a 44 kHz. que le da la tarjeta de sonido. Por software se construye otra señal con freeuncia de muestreo a 130 khz o más interpolando la señal original. Asi se tendría que la detección de positivo a negativo sería más fino. Con eso podría funcionar.
mcleod_ideafix escribió:Además, ya Sinclair se percató de ello. La ZX-Net del Interface 1 no es más que un "EAR" y un "MIC" al que le han quitado todo tipo de filtros: usa un protocolo muy similar al RS232 para transmitir bytes: el receptor se sincroniza con el emisor a nivel de byte, no a nivel de bit. La velocidad efectiva, tal como la pude medir hace meses, es de unos 35 kbps.


Hace poco me leí el manual del Interface I (nunca tuve uno) y lo que más em maravilloó fue lo de poner Spectrums en Red. Creo que ningun otro sistema de la epoca lo tenía.
Para MSX descubrí que se inventaron la "JoyNet" . Una red por el conector Joystick. indicio de que no había nada standard para red de MSX. Para Amstrad no he visto nada.

Tambien le eche un vistazo a la rutina de la Red. Efectivamente es un procolo serie.
Hacerlo con una señal de audio creo que permitiría mayores distancias . Aunque más lento sería más robusto. Y menos critico en la sincronización con maquinas que tienen distintas velocidades de reloj.
Duda
¿la Zx-Net funciona tambien para los +2 que tienen distinta frecuencia de reloj?
xor a
ld R,a
b1 in f,(c)
jp pe , b1
ld a,R

Responder

¿Quién está conectado?

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