Prueba superada. Tenía una espinita clavada con las cargas a 25200 bps que
casi casi funcionaban con versiones anteriores de k7zx.
Una nueva rutina de carga que funciona combinando la medición del tiempo con
el registro R y el ingenioso metodo de las ultracargas de Antonio Villena
para muestrear el pin EAR consigue cargas a 1,75 muestras por bit. Aunque
paradójicamente solo funciona con frecuencia de muestreo de 48kHz con lo que
resultan 27428 bps.

http://personal.auna.com/casariche/k7zx4/k7zx4.htm

Espero que se me perdone que sólo haya una versión en inglés (pura vagancia
para no tener dos versiones)

Además del nuevo record mundial hay cosas más interesantes en k7zx 4.0. La
propia rutina para el record (Raudo) permite que las cargas a 19.600 y
21.333 bps sean coser y cantar.

Muchas rutinas se han optimizado (ultra y delta perimiten cargas por
bloques, S.Slow es todavía más robusta, nueva forma de onda de pulso de
igual energia ideal para Manchester ...)

El viejo programa tap2mp3 se incluye ahora en k7zx y además convierte tzx.

Se añaden nuevos metodos de carga más lentos con la idea de ser utilizados
en reproductores mp3 e incluso cinta magnetica.

La única dificultad con los mp3 es que los reproductores (al menos el mio)
dan un un nivel de salida muy bajo. En el Spectrum+ no hay problema pero el
+3 es un poco sordo. Con un amplificador (por cutre que sea : un grabagor de
cinta en posición REC.PAUSE) problema solucionado.

Para cinta maganetica se obtienen unos resultados sorprendente buenos: 11
kbs!. Bien es cierto que con una cinta un poco especial: una cinta TDK VHS
en un video stereo. Y con un grabador tipo periodista 4.000 bps. Casi no
acabo de creermelo.

¿que más cosas se podrían hacer?

Un hilo en WOS hablaba de los muchos compresores para Spectrum (pero no me
quedó claro que ratio alcazaban). A la hora de cargar snapshot se podrían
comprimir antes. No tiene mucho sentido en cargas más rádidas pero para
cargas más lentas para primar la fiabilidad quizás si.

Definir un standard para extender las cargas rápidas a otros sistemas (msx,
amstrad). Digo esto porque hace un tiempo consegui en el Rastro un msx
HitBit por 5 eurazos y hasta encontré una utilidad cas2wav. Pero como soy un
auténtico novato en msx no conseguí nada. Imaganaos un programa para torpes
(sin tantas opciones como k7zx) : seleccionas la máquina (spectrum,amstrad,
msx), seleccionas el snapshot, tecleas ' LOAD """ ' o lo que se tercie y le
das al play. Con algo tan sencillo quizás muchas máquinas sean reascatadas
de desvanes y trasteros por antigos usuarios o por nuevas generaciones.
¿Alguien se anima?

¡Muchas gracias! Creo que fui el primero en votar tus videos como
excelentes en YouTube.
Poder ver el Spectrum original cargando datos de esta forma es algo
increíble.
Una cosa que aún no logré entender es de donde vienen los nombres que
le has puesto a cada tipo de carga.
Como no tengo un Spectrum aqui en los EUA, he estado haciendo
experiencias a ver que tan rapido se puede cargar los .tzxs en
emuladores. Algunos de los emuladores no 'ven' el bloque turbo, pero
lo importante es que funciona en un Spectrum real.
Te felicito por tan excelente programa.

¡Muchas gracias! Creo que fui el primero en votar tus videos como
excelentes en YouTube.
Poder ver el Spectrum original cargando datos de esta forma es algo
increíble.
Una cosa que aún no logré entender es de donde vienen los nombres que
le has puesto a cada tipo de carga.
Como no tengo un Spectrum aqui en los EUA, he estado haciendo
experiencias a ver que tan rapido se puede cargar los .tzxs en
emuladores. Algunos de los emuladores no 'ven' el bloque turbo, pero
lo importante es que funciona en un Spectrum real.
Te felicito por tan excelente programa.

"Bruno Florindo" <zxspectrum128***gmail.com> escribió en el mensaje
news:1187313954.330972.48480***q3g2000prf.googlegrou ps.com...
¡Muchas gracias! Creo que fui el primero en votar tus videos como
excelentes en YouTube.
Poder ver el Spectrum original cargando datos de esta forma es algo
increíble.
Una cosa que aún no logré entender es de donde vienen los nombres que
le has puesto a cada tipo de carga.
----------------------------

XDD. Algún nombre nombre había que poner. Tiene su historia.

La primera rutina que hice fue "Throwing Milks", que es la traducció literal
al inglés de la expresión española "echando leches". Ir echando leches
quiere decir ir muy deprisa.

Con Throwing Milks conseguí 12.600 bps. Pero estaba lejos del limite teorico
que se conseguí en emulador (tuve suerte de elegir como emulador para el
desarrollo Spectaculator, sin eso quizás nunca habría avanzado).
Investigando porqué esa diferencia descubrí que la entrada EAR del spectrum
provoca una diferencia entre pulsos positivos y negativos segun la
componente continua. Así que se me ocurrió otro metodo de carga sin
componente continua que permitía una precisión de media muestra por pulso si
se medía el ciclo completo. Throwing Shavings traducción literal de "echando
viruta" que es también ir muy deprisa

Con throwing shavings surgieron dos variantes una más conservadora ,Slow (
lento en inglés, esta vez la traducción era correcta, salvo la guasa de
llamar Slow a un rutina que alcazaba 17600 bps), y otra, Delta, que casi
conseguía 25200 (llegué a cargar el manic miner y sonaba la musica pero
luego no se podía jugar). Delta viene porque la onda es una sucesión de
pulsos de ancho fijo.

Luego por brevedad "throwing" se eliminó.

Ultra es en honor de la ultracargas de Antonio Villena que ya funcionaban
desde hacía tiempo. Hice un rutina más compacta y así , con esos cuatro
métodos de carga , salió la primera versión de k7zx.

Non Plus Ultra (no más allá en latín) es el metodo que consigue el la maxima
velocidad posible. No se puede ser rápido.

Pero no funcionaba en una carga real. Una variante de Delta en el que los 00
tuviesen duración cero podría acercarse al máximo teorico de NPU. Era como
si los 00 se escurrieran de la transmisión. Por eso es Escurrido y por lo
mucho que me "escurrí" las neuronas para hacer la rutina.

Desgraciadamente tampoco llegó a funcionar. Con esos dos nuevos metodos sólo
teoricos salió la versión 2.

Como npu no funcionaba a la maxima velocidad vi si era posible que
funcionase a menor velocidad aunque ya exisitien metodos que ya conseguían
esa velocidad. Dado el éxito también pense en el metodo original que utiliza
el espectrum para ver cual sería su máximo aunque no superase otros metodos.
Y desarrollando esa adpatacion se me ocurrió un método nuevo que se parece
bastante a una modulación por fase, de ahí Fi. Y a continuación si a Fi le
aplicamos la tecnica de 2 bit pensé en PWM (pulse width modulation) que
funcionaba bastante mal. Y por último Manchester y Manchester diferencial
que se llaman así porque son técnicas conocidas. Ya por aquí Black Hole
presentó su versión de codificacion manchester.

Asi salió la versión 3

Propiamente el método spectrum original no era tal ya que el spectrum solo
mide semiclos. Así que surgieron ROM (spectrum original autentico) y FSK
(modulacion por frequencia). PWM fue eliminado al descubrir el verdadero
equivalente de fi a 2 bit: Fi Quadruple que funciona razonablemente.

Al presentar la versión 3 en WOS surgieron dos inquietudes: si era posible
velocidad más lentas (casi parecía una tomadura de pelo) y si era posible
que funcionase en mp3 (alguien lo consiguió cuando no pensé que sería
factible) Entonces había que hacer métodos no tan rápidos ("Ma non tropo"
expresión italiana para la música que significa "pero no demasiado").

Andante , allegro, vivace y presto son también palabras italianas que en
música expresan el tempo con que se debe ejecutar una partitura (la
velocidad). En principio allegro (6000 bps) solo iba a ser uno pero se me
ocurrieron tres variantes pensando que 6000 iba a ser el limite para una
cinta magnetica

Por ultimo afronté el desafio que me quedaba pendiente consguir una carga a
1,75 muestra/bit en un spectrum real. la solución fue Raudo (raudo es
rápido)

Y así ha resultado la versión 4

..............................

Como no tengo un Spectrum aqui en los EUA, he estado haciendo
experiencias a ver que tan rapido se puede cargar los .tzxs en
emuladores.

------------------------------------

¿Por qué no pruebas en un Timex?
Antonio Villena hizo una apadtación en su rutina y funcionó en un timex.

Según entiendo la diferencia clave va a ser la velocidad del reloj. Eso no
debe ser ningun problema con el metodo Fi. Prueba Fi a 6 samples/bit.

para otros metodos quizá haya que ajustar algunos parametros en la rutina.
Puedes incluso hacerlo tu mismo. Si te fijas en los fichero en ensamblador
siempre hay una lineas con las etiquetas K0 y K1. Pokeando estos parametros
se pueden hacer ajustes facilmente.

Estaría bien poder definir un metodo standard de carga rápida que funcone
para todos lo modelos de Spetrum incluido timex

.................................................


Algunos de los emuladores no 'ven' el bloque turbo, pero
lo importante es que funciona en un Spectrum real.
Te felicito por tan excelente programa.

"Bruno Florindo" <zxspectrum128***gmail.com> escribió en el mensaje
news:1187313954.330972.48480***q3g2000prf.googlegrou ps.com...
¡Muchas gracias! Creo que fui el primero en votar tus videos como
excelentes en YouTube.
Poder ver el Spectrum original cargando datos de esta forma es algo
increíble.
Una cosa que aún no logré entender es de donde vienen los nombres que
le has puesto a cada tipo de carga.
----------------------------

XDD. Algún nombre nombre había que poner. Tiene su historia.

La primera rutina que hice fue "Throwing Milks", que es la traducció literal
al inglés de la expresión española "echando leches". Ir echando leches
quiere decir ir muy deprisa.

Con Throwing Milks conseguí 12.600 bps. Pero estaba lejos del limite teorico
que se conseguí en emulador (tuve suerte de elegir como emulador para el
desarrollo Spectaculator, sin eso quizás nunca habría avanzado).
Investigando porqué esa diferencia descubrí que la entrada EAR del spectrum
provoca una diferencia entre pulsos positivos y negativos segun la
componente continua. Así que se me ocurrió otro metodo de carga sin
componente continua que permitía una precisión de media muestra por pulso si
se medía el ciclo completo. Throwing Shavings traducción literal de "echando
viruta" que es también ir muy deprisa

Con throwing shavings surgieron dos variantes una más conservadora ,Slow (
lento en inglés, esta vez la traducción era correcta, salvo la guasa de
llamar Slow a un rutina que alcazaba 17600 bps), y otra, Delta, que casi
conseguía 25200 (llegué a cargar el manic miner y sonaba la musica pero
luego no se podía jugar). Delta viene porque la onda es una sucesión de
pulsos de ancho fijo.

Luego por brevedad "throwing" se eliminó.

Ultra es en honor de la ultracargas de Antonio Villena que ya funcionaban
desde hacía tiempo. Hice un rutina más compacta y así , con esos cuatro
métodos de carga , salió la primera versión de k7zx.

Non Plus Ultra (no más allá en latín) es el metodo que consigue el la maxima
velocidad posible. No se puede ser rápido.

Pero no funcionaba en una carga real. Una variante de Delta en el que los 00
tuviesen duración cero podría acercarse al máximo teorico de NPU. Era como
si los 00 se escurrieran de la transmisión. Por eso es Escurrido y por lo
mucho que me "escurrí" las neuronas para hacer la rutina.

Desgraciadamente tampoco llegó a funcionar. Con esos dos nuevos metodos sólo
teoricos salió la versión 2.

Como npu no funcionaba a la maxima velocidad vi si era posible que
funcionase a menor velocidad aunque ya exisitien metodos que ya conseguían
esa velocidad. Dado el éxito también pense en el metodo original que utiliza
el espectrum para ver cual sería su máximo aunque no superase otros metodos.
Y desarrollando esa adpatacion se me ocurrió un método nuevo que se parece
bastante a una modulación por fase, de ahí Fi. Y a continuación si a Fi le
aplicamos la tecnica de 2 bit pensé en PWM (pulse width modulation) que
funcionaba bastante mal. Y por último Manchester y Manchester diferencial
que se llaman así porque son técnicas conocidas. Ya por aquí Black Hole
presentó su versión de codificacion manchester.

Asi salió la versión 3

Propiamente el método spectrum original no era tal ya que el spectrum solo
mide semiclos. Así que surgieron ROM (spectrum original autentico) y FSK
(modulacion por frequencia). PWM fue eliminado al descubrir el verdadero
equivalente de fi a 2 bit: Fi Quadruple que funciona razonablemente.

Al presentar la versión 3 en WOS surgieron dos inquietudes: si era posible
velocidad más lentas (casi parecía una tomadura de pelo) y si era posible
que funcionase en mp3 (alguien lo consiguió cuando no pensé que sería
factible) Entonces había que hacer métodos no tan rápidos ("Ma non tropo"
expresión italiana para la música que significa "pero no demasiado").

Andante , allegro, vivace y presto son también palabras italianas que en
música expresan el tempo con que se debe ejecutar una partitura (la
velocidad). En principio allegro (6000 bps) solo iba a ser uno pero se me
ocurrieron tres variantes pensando que 6000 iba a ser el limite para una
cinta magnetica

Por ultimo afronté el desafio que me quedaba pendiente consguir una carga a
1,75 muestra/bit en un spectrum real. la solución fue Raudo (raudo es
rápido)

Y así ha resultado la versión 4

..............................

Como no tengo un Spectrum aqui en los EUA, he estado haciendo
experiencias a ver que tan rapido se puede cargar los .tzxs en
emuladores.

------------------------------------

¿Por qué no pruebas en un Timex?
Antonio Villena hizo una apadtación en su rutina y funcionó en un timex.

Según entiendo la diferencia clave va a ser la velocidad del reloj. Eso no
debe ser ningun problema con el metodo Fi. Prueba Fi a 6 samples/bit.

para otros metodos quizá haya que ajustar algunos parametros en la rutina.
Puedes incluso hacerlo tu mismo. Si te fijas en los fichero en ensamblador
siempre hay una lineas con las etiquetas K0 y K1. Pokeando estos parametros
se pueden hacer ajustes facilmente.

Estaría bien poder definir un metodo standard de carga rápida que funcone
para todos lo modelos de Spetrum incluido timex

.................................................


Algunos de los emuladores no 'ven' el bloque turbo, pero
lo importante es que funciona en un Spectrum real.
Te felicito por tan excelente programa.

> Prueba superada. Tenía una espinita clavada con las cargas a 25200 bps que
> casi casi funcionaban con versiones anteriores dek7zx.
> Una nueva rutina de carga que funciona combinando la medición del tiempo con
> el registro R y el ingenioso metodo de las ultracargas de Antonio Villena
> para muestrear el pin EAR consigue cargas a 1,75 muestras por bit. Aunque
> paradójicamente solo funciona con frecuencia de muestreo de 48kHz con lo que
> resultan 27428 bps.
>
> http://personal.auna.com/casariche/k7zx4/k7zx4.htm
>

Enhorabuena. Ya era hora que alguien lo consiguiera. He visto en
tu página que tienes una tabla de samples/bit donde las 4 variantes
más rápidas son 1.25, 1.5, 1.75 y 2. A bote pronto, se me ocurren
métodos de 1 bit por símbolo y de 2 bits por símbolo. Los de 2 bits
por símbolo son los que tienen 4 sumandos.

A) 1+2+3+4 = 10/8 = 1.25

B1) 1+2 = 3/2 = 1.5
B2) 1+2+4+5 = 12/8 = 1.5 Ligeramente inútil
B2) 1+2+3+6 = 12/8 = 1.5 Inútil

C) 2+3+4+5 = 14/8 = 1.75

D1) 1+3+5+7 = 16/8 = 2 Genial (los símbolos están separados 2
muestras)
D2) x+y+z+t = 16 Cualquier otra combinación hará que al menos 2
símbolos estén a 1 muestra de distancia.
D3) 1+3 = 4/2 = 2 Igual de genial que D1, pero más sencillo.

Para la velocidad que has conseguido no se me ocurre otro método
distinto al C, corrígeme si me equivoco. Bueno el caso es que tanto C
como A tienen la misma separación entre símbolos, y por tanto, la
misma probabilidad de error. La única diferencia es que en A hay que
ser muy rápido, ya que el símbolo de 1 muestra es muy crítico (80
ciclos) y además hay que procesar 2 bits.

Espero que llegues a 1.25, que supondrán 35280 y 38400 bps (a 44100 y
48000 m/s). Yo en su día probé lo del 1.25, pero solo me funcionaba
bajo emuladores. Desgraciadamente no conservo el código fuente,
aunque puedes depurarlo cargando el wav en spectaculator. Si te sirve
te lo dejo aquí, es un manic miner que tarda 6 segundos en cargar,
bloque basic incluído.
http://www.antoniovillena.es/ultra/manic.zip

> Espero que se me perdone que sólo haya una versión en inglés (pura vagancia
> para no tener dos versiones)
>
> Además del nuevo record mundial hay cosas más interesantes enk7zx4.0.La
> propia rutina para el record (Raudo) permite que las cargas a 19.600 y
> 21.333 bps sean coser y cantar.
>
> Muchas rutinas se han optimizado (ultra y delta perimiten cargas por
> bloques, S.Slow es todavía más robusta, nueva forma de onda de pulso de
> igual energia ideal para Manchester ...)
>
> El viejo programa tap2mp3 se incluye ahora enk7zxy además convierte tzx.
>
> Se añaden nuevos metodos de carga más lentos con la idea de ser utilizados
> en reproductores mp3 e incluso cinta magnetica.
>
> La única dificultad con los mp3 es que los reproductores (al menos el mio)
> dan un un nivel de salida muy bajo. En el Spectrum+ no hay problema pero el
> +3 es un poco sordo. Con un amplificador (por cutre que sea : un grabagorde
> cinta en posición REC.PAUSE) problema solucionado.
>
> Para cinta maganetica se obtienen unos resultados sorprendente buenos: 11
> kbs!. Bien es cierto que con una cinta un poco especial: una cinta TDK VHS
> en un video stereo. Y con un grabador tipo periodista 4.000 bps. Casi no
> acabo de creermelo.
>
> ¿que más cosas se podrían hacer?
>
> Un hilo en WOS hablaba de los muchos compresores para Spectrum (pero no me
> quedó claro que ratio alcazaban). A la hora de cargar snapshot se podrían
> comprimir antes. No tiene mucho sentido en cargas más rádidas pero para
> cargas más lentas para primar la fiabilidad quizás si.
>
> Definir un standard para extender las cargas rápidas a otros sistemas (msx,
> amstrad). Digo esto porque hace un tiempo consegui en el Rastro un msx
> HitBit por 5 eurazos y hasta encontré una utilidad cas2wav. Pero como soy un
> auténtico novato en msx no conseguí nada. Imaganaos un programa para torpes
> (sin tantas opciones comok7zx) : seleccionas la máquina (spectrum,amstrad,
> msx), seleccionas el snapshot, tecleas ' LOAD """ ' o lo que se tercie yle
> das al play. Con algo tan sencillo quizás muchas máquinas sean reascatadas
> de desvanes y trasteros por antigos usuarios o por nuevas generaciones.
> ¿Alguien se anima?

Vaya cantidad de cargadores distintos tienes. No se me hubiera
ocurrido que alguien llegara a este nivel. Yo tengo ya el tema de las
ultracargas olvidado, pero me agrada saber que todavía sigue vivo.
Voy a dejar unos cuantos enlaces de todo lo que he podido rescatar.
El sna2wav.jar creo que lo he perdido, soy un poco desastre.
http://www.antoniovillena.es/ultra/codigofuente.zip
http://www.antoniovillena.es/ultra/ejecutables.zip
http://www.antoniovillena.es/ultra/ejemplo.zip
http://www.antoniovillena.es/ultra/sna2tzx.zip

En cuanto al tema de la compresión, no hace falta que busques mucho,
el único método factible es el LZ77. Si usas Huffman o Shanon Fano
para aumentar el ratio, ralentizarás bastante el tiempo de
descompresión, y no te compensará en tiempo global. Yo uso una
variante LZ77 muy buena con ratios ZIP equivalentes y tiempo de
descompresión rapidísimo. Lo malo es que está en ensamblador: es el
tc.asm que está en codigofuente.zip.

Bueno, espero que con tus ultracargas la gente vaya desempolvando
los viejos spectrums, que con un mp3 de los de ahora se pueden cargar
muchos juegos casi instantáneamente. Los emuladores están bien pero
donde se ponga un gomas... También estoy a la espera que Alessandro
Poppi saque ya su ZXMMC+ de una vez.

Saludos
Antonio Villena

> Prueba superada. Tenía una espinita clavada con las cargas a 25200 bps que
> casi casi funcionaban con versiones anteriores dek7zx.
> Una nueva rutina de carga que funciona combinando la medición del tiempo con
> el registro R y el ingenioso metodo de las ultracargas de Antonio Villena
> para muestrear el pin EAR consigue cargas a 1,75 muestras por bit. Aunque
> paradójicamente solo funciona con frecuencia de muestreo de 48kHz con lo que
> resultan 27428 bps.
>
> http://personal.auna.com/casariche/k7zx4/k7zx4.htm
>

Enhorabuena. Ya era hora que alguien lo consiguiera. He visto en
tu página que tienes una tabla de samples/bit donde las 4 variantes
más rápidas son 1.25, 1.5, 1.75 y 2. A bote pronto, se me ocurren
métodos de 1 bit por símbolo y de 2 bits por símbolo. Los de 2 bits
por símbolo son los que tienen 4 sumandos.

A) 1+2+3+4 = 10/8 = 1.25

B1) 1+2 = 3/2 = 1.5
B2) 1+2+4+5 = 12/8 = 1.5 Ligeramente inútil
B2) 1+2+3+6 = 12/8 = 1.5 Inútil

C) 2+3+4+5 = 14/8 = 1.75

D1) 1+3+5+7 = 16/8 = 2 Genial (los símbolos están separados 2
muestras)
D2) x+y+z+t = 16 Cualquier otra combinación hará que al menos 2
símbolos estén a 1 muestra de distancia.
D3) 1+3 = 4/2 = 2 Igual de genial que D1, pero más sencillo.

Para la velocidad que has conseguido no se me ocurre otro método
distinto al C, corrígeme si me equivoco. Bueno el caso es que tanto C
como A tienen la misma separación entre símbolos, y por tanto, la
misma probabilidad de error. La única diferencia es que en A hay que
ser muy rápido, ya que el símbolo de 1 muestra es muy crítico (80
ciclos) y además hay que procesar 2 bits.

Espero que llegues a 1.25, que supondrán 35280 y 38400 bps (a 44100 y
48000 m/s). Yo en su día probé lo del 1.25, pero solo me funcionaba
bajo emuladores. Desgraciadamente no conservo el código fuente,
aunque puedes depurarlo cargando el wav en spectaculator. Si te sirve
te lo dejo aquí, es un manic miner que tarda 6 segundos en cargar,
bloque basic incluído.
http://www.antoniovillena.es/ultra/manic.zip

> Espero que se me perdone que sólo haya una versión en inglés (pura vagancia
> para no tener dos versiones)
>
> Además del nuevo record mundial hay cosas más interesantes enk7zx4.0.La
> propia rutina para el record (Raudo) permite que las cargas a 19.600 y
> 21.333 bps sean coser y cantar.
>
> Muchas rutinas se han optimizado (ultra y delta perimiten cargas por
> bloques, S.Slow es todavía más robusta, nueva forma de onda de pulso de
> igual energia ideal para Manchester ...)
>
> El viejo programa tap2mp3 se incluye ahora enk7zxy además convierte tzx.
>
> Se añaden nuevos metodos de carga más lentos con la idea de ser utilizados
> en reproductores mp3 e incluso cinta magnetica.
>
> La única dificultad con los mp3 es que los reproductores (al menos el mio)
> dan un un nivel de salida muy bajo. En el Spectrum+ no hay problema pero el
> +3 es un poco sordo. Con un amplificador (por cutre que sea : un grabagorde
> cinta en posición REC.PAUSE) problema solucionado.
>
> Para cinta maganetica se obtienen unos resultados sorprendente buenos: 11
> kbs!. Bien es cierto que con una cinta un poco especial: una cinta TDK VHS
> en un video stereo. Y con un grabador tipo periodista 4.000 bps. Casi no
> acabo de creermelo.
>
> ¿que más cosas se podrían hacer?
>
> Un hilo en WOS hablaba de los muchos compresores para Spectrum (pero no me
> quedó claro que ratio alcazaban). A la hora de cargar snapshot se podrían
> comprimir antes. No tiene mucho sentido en cargas más rádidas pero para
> cargas más lentas para primar la fiabilidad quizás si.
>
> Definir un standard para extender las cargas rápidas a otros sistemas (msx,
> amstrad). Digo esto porque hace un tiempo consegui en el Rastro un msx
> HitBit por 5 eurazos y hasta encontré una utilidad cas2wav. Pero como soy un
> auténtico novato en msx no conseguí nada. Imaganaos un programa para torpes
> (sin tantas opciones comok7zx) : seleccionas la máquina (spectrum,amstrad,
> msx), seleccionas el snapshot, tecleas ' LOAD """ ' o lo que se tercie yle
> das al play. Con algo tan sencillo quizás muchas máquinas sean reascatadas
> de desvanes y trasteros por antigos usuarios o por nuevas generaciones.
> ¿Alguien se anima?

Vaya cantidad de cargadores distintos tienes. No se me hubiera
ocurrido que alguien llegara a este nivel. Yo tengo ya el tema de las
ultracargas olvidado, pero me agrada saber que todavía sigue vivo.
Voy a dejar unos cuantos enlaces de todo lo que he podido rescatar.
El sna2wav.jar creo que lo he perdido, soy un poco desastre.
http://www.antoniovillena.es/ultra/codigofuente.zip
http://www.antoniovillena.es/ultra/ejecutables.zip
http://www.antoniovillena.es/ultra/ejemplo.zip
http://www.antoniovillena.es/ultra/sna2tzx.zip

En cuanto al tema de la compresión, no hace falta que busques mucho,
el único método factible es el LZ77. Si usas Huffman o Shanon Fano
para aumentar el ratio, ralentizarás bastante el tiempo de
descompresión, y no te compensará en tiempo global. Yo uso una
variante LZ77 muy buena con ratios ZIP equivalentes y tiempo de
descompresión rapidísimo. Lo malo es que está en ensamblador: es el
tc.asm que está en codigofuente.zip.

Bueno, espero que con tus ultracargas la gente vaya desempolvando
los viejos spectrums, que con un mp3 de los de ahora se pueden cargar
muchos juegos casi instantáneamente. Los emuladores están bien pero
donde se ponga un gomas... También estoy a la espera que Alessandro
Poppi saque ya su ZXMMC+ de una vez.

Saludos
Antonio Villena

"Espineter" <espineter***gmail.com> escribió en el mensaje
news:1187936299.177886.134770***e9g2000prf.googlegro ups.com...




> Enhorabuena. Ya era hora que alguien lo consiguiera. He visto en
>tu página que tienes una tabla de samples/bit donde las 4 variantes
>más rápidas son 1.25, 1.5, 1.75 y 2. A bote pronto, se me ocurren
>métodos de 1 bit por símbolo y de 2 bits por símbolo. Los de 2 bits
>por símbolo son los que tienen 4 sumandos.
>
>A) 1+2+3+4 = 10/8 = 1.25

Esa es Non PLus Ultra a 1.25

>B1) 1+2 = 3/2 = 1.5

Ultra a 1.5

>B2) 1+2+4+5 = 12/8 = 1.5 Ligeramente inútil
>B2) 1+2+3+6 = 12/8 = 1.5 Inútil

Esas no están.


>C) 2+3+4+5 = 14/8 = 1.75

Shavings y NPU a 1.75


>D1) 1+3+5+7 = 16/8 = 2 Genial (los símbolos están separados 2 muestras)

NPU a 2. Sí, es buena; llega a funcionar sin mucho problema en el Spectrum+
pero en +3 no.

>D2) x+y+z+t = 16 Cualquier otra combinación hará que al menos 2 símbolos
estén
>a 1 muestra de distancia.
>D3) 1+3 = 4/2 = 2 Igual de genial que D1, pero más sencillo.

Ultra a 2. También muy buena. Con una ajuste fino de volumen funciona en
ambos modelos de Spectrum. Pero lamentablemente solo lo he conseguido a
44100 khz.

>Para la velocidad que has conseguido no se me ocurre otro método distinto
al C,
>corrígeme si me equivoco.


Hay otro. El que utiliza FiQ: 3+3+4+4 .


>Bueno el caso es que tanto C
>como A tienen la misma separación entre símbolos, y por tanto, la
>misma probabilidad de error. La única diferencia es que en A hay que
>ser muy rápido, ya que el símbolo de 1 muestra es muy crítico (80
>ciclos) y además hay que procesar 2 bits.

Aunque cerca del limite la velocidad de proceso del Spectrum no es problema,
puede muestrar como un campeón señales de 24kHz.
El problema es que aunque la separación entre simbolos es teoricamente la
misma
hay una diferencia notable entre medir pulsos y medir ciclos completos
(un pulso negativo más uno positivo) como hace shavings.
Si suponemos un tren de pulsos de una sola muestra -1+1-1+1-1+1-1+1.. o de
dos
-2+2-2+2-2+2-2+2... no hay ningún problema en decodificar la señal.
Pero para este tren de pulsos: -1+2-1+2-1+2-1+2 la señal se desequilibra y
lo que
el Spectrum ve es algo más parecido a esto -1.3+1.7-1.3+1.7-1.3+1.7...
Entonces la
separacion entre simbolos es de solo .5 muestras o menos.

La idea de las formas de onda "compensar continua" y "pulsos de igual
energia"
surgió precisamente para compensar este efecto. Se nota diferencia y mejora
pero
no es suficiente.


>Espero que llegues a 1.25, que supondrán 35280 y 38400 bps (a 44100 y
>48000 m/s).

Por lo anterior parece que va a ser imposible. En todo caso antes habría que
llegar antes a 1.5 con el metodo ultra. Y está, ya digo, muy complicado.

>Yo en su día probé lo del 1.25, pero solo me funcionaba
>bajo emuladores. Desgraciadamente no conservo el código fuente,
>aunque puedes depurarlo cargando el wav en spectaculator. Si te sirve
>te lo dejo aquí, es un manic miner que tarda 6 segundos en cargar,
>bloque basic incluído.
>http://www.antoniovillena.es/ultra/manic.zip

Parte de ese codigo lo utilizo en el programa ZinetriX. Cargar pantallas a
38400
si vale porque algun error en pocos pixel no es problema.


> En cuanto al tema de la compresión, no hace falta que busques mucho,
>el único método factible es el LZ77. Si usas Huffman o Shanon Fano
>para aumentar el ratio, ralentizarás bastante el tiempo de
>descompresión, y no te compensará en tiempo global. Yo uso una
>variante LZ77 muy buena con ratios ZIP equivalentes y tiempo de
>descompresión rapidísimo. Lo malo es que está en ensamblador: es el
>tc.asm que está en codigofuente.zip.

Más que por tiempo de carga la compresión merecería la pena para tener wavs
o
mp3 más pequeños.

------ (1) ------ (2) ------
| .sna |=> | .tap |=> | .wav |
------ ------ ------

(1) sería el compresor que genera un fichero .tap (con su pequeño cargador
y su bloque de bytes autodescomprimibles)
(2) sería k7xz

Pero se pierde el encanto de ver como se carga no instantaneamente la
pantalla
de carga. 8-)

"Espineter" <espineter***gmail.com> escribió en el mensaje
news:1187936299.177886.134770***e9g2000prf.googlegro ups.com...




> Enhorabuena. Ya era hora que alguien lo consiguiera. He visto en
>tu página que tienes una tabla de samples/bit donde las 4 variantes
>más rápidas son 1.25, 1.5, 1.75 y 2. A bote pronto, se me ocurren
>métodos de 1 bit por símbolo y de 2 bits por símbolo. Los de 2 bits
>por símbolo son los que tienen 4 sumandos.
>
>A) 1+2+3+4 = 10/8 = 1.25

Esa es Non PLus Ultra a 1.25

>B1) 1+2 = 3/2 = 1.5

Ultra a 1.5

>B2) 1+2+4+5 = 12/8 = 1.5 Ligeramente inútil
>B2) 1+2+3+6 = 12/8 = 1.5 Inútil

Esas no están.


>C) 2+3+4+5 = 14/8 = 1.75

Shavings y NPU a 1.75


>D1) 1+3+5+7 = 16/8 = 2 Genial (los símbolos están separados 2 muestras)

NPU a 2. Sí, es buena; llega a funcionar sin mucho problema en el Spectrum+
pero en +3 no.

>D2) x+y+z+t = 16 Cualquier otra combinación hará que al menos 2 símbolos
estén
>a 1 muestra de distancia.
>D3) 1+3 = 4/2 = 2 Igual de genial que D1, pero más sencillo.

Ultra a 2. También muy buena. Con una ajuste fino de volumen funciona en
ambos modelos de Spectrum. Pero lamentablemente solo lo he conseguido a
44100 khz.

>Para la velocidad que has conseguido no se me ocurre otro método distinto
al C,
>corrígeme si me equivoco.


Hay otro. El que utiliza FiQ: 3+3+4+4 .


>Bueno el caso es que tanto C
>como A tienen la misma separación entre símbolos, y por tanto, la
>misma probabilidad de error. La única diferencia es que en A hay que
>ser muy rápido, ya que el símbolo de 1 muestra es muy crítico (80
>ciclos) y además hay que procesar 2 bits.

Aunque cerca del limite la velocidad de proceso del Spectrum no es problema,
puede muestrar como un campeón señales de 24kHz.
El problema es que aunque la separación entre simbolos es teoricamente la
misma
hay una diferencia notable entre medir pulsos y medir ciclos completos
(un pulso negativo más uno positivo) como hace shavings.
Si suponemos un tren de pulsos de una sola muestra -1+1-1+1-1+1-1+1.. o de
dos
-2+2-2+2-2+2-2+2... no hay ningún problema en decodificar la señal.
Pero para este tren de pulsos: -1+2-1+2-1+2-1+2 la señal se desequilibra y
lo que
el Spectrum ve es algo más parecido a esto -1.3+1.7-1.3+1.7-1.3+1.7...
Entonces la
separacion entre simbolos es de solo .5 muestras o menos.

La idea de las formas de onda "compensar continua" y "pulsos de igual
energia"
surgió precisamente para compensar este efecto. Se nota diferencia y mejora
pero
no es suficiente.


>Espero que llegues a 1.25, que supondrán 35280 y 38400 bps (a 44100 y
>48000 m/s).

Por lo anterior parece que va a ser imposible. En todo caso antes habría que
llegar antes a 1.5 con el metodo ultra. Y está, ya digo, muy complicado.

>Yo en su día probé lo del 1.25, pero solo me funcionaba
>bajo emuladores. Desgraciadamente no conservo el código fuente,
>aunque puedes depurarlo cargando el wav en spectaculator. Si te sirve
>te lo dejo aquí, es un manic miner que tarda 6 segundos en cargar,
>bloque basic incluído.
>http://www.antoniovillena.es/ultra/manic.zip

Parte de ese codigo lo utilizo en el programa ZinetriX. Cargar pantallas a
38400
si vale porque algun error en pocos pixel no es problema.


> En cuanto al tema de la compresión, no hace falta que busques mucho,
>el único método factible es el LZ77. Si usas Huffman o Shanon Fano
>para aumentar el ratio, ralentizarás bastante el tiempo de
>descompresión, y no te compensará en tiempo global. Yo uso una
>variante LZ77 muy buena con ratios ZIP equivalentes y tiempo de
>descompresión rapidísimo. Lo malo es que está en ensamblador: es el
>tc.asm que está en codigofuente.zip.

Más que por tiempo de carga la compresión merecería la pena para tener wavs
o
mp3 más pequeños.

------ (1) ------ (2) ------
| .sna |=> | .tap |=> | .wav |
------ ------ ------

(1) sería el compresor que genera un fichero .tap (con su pequeño cargador
y su bloque de bytes autodescomprimibles)
(2) sería k7xz

Pero se pierde el encanto de ver como se carga no instantaneamente la
pantalla
de carga. 8-)

"Inapetente" <alguien***microsoft.com> escribió en el mensaje
news:IqVAi.38609$224.838***news.ono.com...
>

Se me olvidaba. Está actualizado k7zx la version a 4.2. Corrige unos bug

- no se lanzaba el lame.exe cuando esta en un path con algún espacio
- Algunos de conversion de tzx a la velocidad normal