Propuesta de estándar para carga de alta velocidad

[decicoder]

Por sugerencua de zyloj presento un pequeño documento para definir una carga a alta velocidad que pueda ser un estandar. Queda abierto el debate para proponer mejoras o descartar inconvenientes.

http://personal.auna.com/casariche/docs ... rapida.htm

Se incluye un codigo fuente comentado mas o menoes en detalle.

[zyloj]

Mucho debate parece que no hay...

En cuestiones técnicas, yo no puedo colaborar, pero sí que hay lugar para aportar la mayor cantidad posible de pruebas con diferentes equipos. Supongo que tocará partir de un generador de ultracargas y afinar las características que lo acoten a base de nuestras experiencias. Después será cuestión de publicar el código fuente para aquellos que quieran usar el sistema en nuevas producciones. De esta forma nos servirá para crear nuestras propias cargas de juegos antiguos y para facilitar la expansión de los nuevos desarrollos usados en la máquina original.

La idea es que este método nos sirva a todos facilitando una carga rápida y fiable de forma barata. ¿Quien no tiene discman, pc o mp3 disponible a estas alturas?

Por mi parte, sugiero que el sistema valga para cualquiera de los diferentes modelos de Spectrum, y facilite la inclusión en la carga de pantallas de presentación. Por otro lado también nos interesaría que sirva para programas 48 y 128 (me suena que algunos de los métodos que has ido desarrollando no eran válidos para los segundos).

¿Alguien tiene pensada alguna sugerencia?

Saludos

[decicoder]

Mucho debate parece que no hay...

Pues adjudicado.

En cuestiones técnicas, yo no puedo colaborar, pero sí que hay lugar para aportar la mayor cantidad posible de pruebas con diferentes equipos.

¿Has hecho pruebas con reproducor mp3?
La mayor parte de mis pruebas simpre son con tarjeta de sonido.
Para cd pienso que no habrá mayor problema.
Con mp3 la mayor dificultad puede ser el volumen de salida del reproductor y el punto critico de la detección del sincronismo.

Por otro lado también nos interesaría que sirva para programas 48 y 128 (me suena que algunos de los métodos que has ido desarrollando no eran válidos para los segundos).

las primeras versiones no soportaban snapshot de 128k. Ahora sí aunque quizá no esté muy fino; no se recupera los registros de chip de sonido. No sé que importancia puede tener eso.


buscando por la red he encontrado otras carga rapida para otros sistemas.

para msx existe MicroWaver:
http://cax.narod.ru/msx/packed/index.html

Un programa hecho por un ruso a partir de un porgrama de un español. Consiguieron
en 2005 unos apreciables 5512 bps. Y utlizan tecnicas de compresión

Para Amstrad he visto que las especificaciones origianles hablan de que permite
grabar en cinta hasta 19200 baudios. ¿Será puro marqueting?.

[zyloj]

¿Has hecho pruebas con reproducor mp3?

Lo cierto es que no. Hasta ahora todas las pruebas las he hecho desde cd. El mayor problema que me ha surgido hasta ahora ha sido que el wav producido por la utilidad no tuviera el volumen suficiente para el Spectrum. Lo soluciono con programas de edición que lo incrementen, con lo cual ya no dan problema en la carga (aunque con según que variantes, no sirve). Habría que ver si con otros discman se repetía el problema. De todas formas, a estas alturas, el cd puede que esté en peligro de extinción...

Por otra parte, me faltaría hacer pruebas con el Spectrum plus, que en estos momentos lo tengo fuera de combate por la membrana de teclado. Tengo curiosidad por ver que tal se comporta...

Saludos

[WYZ]

@Decicoder:con MW puedes conseguir velocidades muy superiores pero la que podría considerar standard para la calidad de un reproductor de CD es la que apunta la pagina de Cax, 5512 es fácil ver de donde sale ese número. (Aclarar que Cax me ayudo mucho en el tema del lanzador , que yo tenia hecho en Visual Basic añadiéndole algunas opciones de carga y me propuso la compresión de wav a Mp3).

Las pruebas hechas por Cax usando LAME como codificador de MP3 dieron excelentes resultado. Ahora, con reproductores de gran calidad podría aumentar ostensiblemente el caudal de datos por segundo. Con mi tarjeta de sonido antigua, una SBLive!, 6 kbps dan una fiabilidad del 100%.


MW usa doble compresión: una compresion huffman para los datos de audio y bitbuster ( en mi ultima versión no liberada, pucrunch) para la compresión del archivo en si.

No te recomiendo PARA NADA el uso de un emulador para pruebas.

[decicoder]

@Decicoder:con MW puedes conseguir velocidades muy superiores pero la que podría considerar standard para la calidad de un reproductor de CD es la que apunta la pagina de Cax, 5512 es fácil ver de donde sale ese número. (Aclarar que Cax me ayudo mucho en el tema del lanzador , que yo tenia hecho en Visual Basic añadiéndole algunas opciones de carga y me propuso la compresión de wav a Mp3).

Probe el microwaver pero mirando el wav no llegué a entender como funcionaba. ¿Puedo ver el codigo fuente de la rutina cargadora?

Es extraño que un MSX no pueda superar a un spectrum . (Que nadie se enfade)

El Spectrum es más patatónico comparado con el MSX en un aspecto: la memoria contenida.

Cuando en un Spectrum haces un in a, (c) o un out (C),A (nos gusta ver colorines en le borde mientras se carga) no se tarda un tiempo fijo de 12 t-states; puedes tardar de 0 a 6 tsates más dependiento de si la ULA está referescando la pantalla.

Precisamente hace tiempo cuando empezé con k7zx y aprendí estás cosas descubrí por casualidad que MSX lo hace de una manera más elegante. Retrasa 1 tstate por cada instrucción. Eso hace que sea más lento pero tienes la garantía de que que puedes medir el tiempo con exactitud. Que es lo que nos interesa para medir ciclos de onda.

Además la rutina de Otla fuciona perfectamente en un 48k y en un +3. Y ojo al dato: estás dos maquinas tienen frecuencias de reloj distintas. Cosa que , segun creo, con los MSX afortunadamente no pasa.

Es spectrum es pues el candidato más desfaroble para que funcione. El amstrad tiene un reloj de 4Mhz con lo que el puñetero va más holgado muestreando el puerto.

Salvo la parte del convertidor analogico digital. A lo mejor da la casualidad de que el espectrum es muy bueno para estos menesteres de la alta velocidad, eso es lo que hay que ver. Por las primeras pruebas soy optimista con msx y amstrad.

Las pruebas hechas por Cax usando LAME como codificador de MP3 dieron excelentes resultado. Ahora, con reproductores de gran calidad podría aumentar ostensiblemente el caudal de datos por segundo. Con mi tarjeta de sonido antigua, una SBLive!, 6 kbps dan una fiabilidad del 100%.

k7zx también convierte con lame. Y según mi experiencia es mejor la opción fast que quality. Que experiencia tenéis?

MW usa doble compresión: una compresion huffman para los datos de audio y bitbuster ( en mi ultima versión no liberada, pucrunch) para la compresión del archivo en si.

La compresión será la fase final. Incluso como opción. Quizá alguno prefiera esperar un poco más y oir un ruido más familiar y con ritmo. El de los datos comprimidos es muy monotono . 8-D.

No te recomiendo PARA NADA el uso de un emulador para pruebas.

desde luego la rutina se tiene que ajustar sobre una maquina real.

[WYZ]

Probado en MSX con exito!

Enhorabuena Decicoder.


A pelo:

Manic Miner: 17s

Dos ejemplos:

Previa compresión con prucrunch:

- HYPE 32kb:. 14s
- Infinity 16kb: 18s

[chelnov]

Perdonad mi ignorancia, pero ¿hay algún tipo de ultracarga del k7zx que no corrompa la pantalla de presentación?

Muchas gracias

[Ralphy]

Usuario Chelnov, siento decir que desde siempre, cualquier interface o artilugio de hacer volcados de programas siempre deja "esa huella" en las pantallas de carga, ninguno de salva (Los famosos transtapes de mediados de los 80's, por ejemplo, siempre dejan 4 rayas en la parte superior del screen$, ahora los k7zx dejan más en la mitad del mismo screen$).

Hace muchísimo tiempo, yo personálmente apodaba a los artilugios esos como "los violadores", ya que "siempre dejan secuelas" (en la pantalla, claro está). Normálmente llamamos a las rayas que dejan en los screen$ "basura". Lo importante es que los k7zx funcionan y es algo innovador. Si ahora nos sorprende, ¿ qué hubiera sido si algo así se hubiera practicado a mediados de los 80's en aquellos 8086 o 286 de entonces ? La palabra "bombazo de los 8 bits" se queda corta.

Esto de la basura me recuerda a muchos juegos piratas en cuyo 2º bloque cm "se pisa" obligatóriamente el dibujo anterior, pero sin ese bloque no funciona el juego (Parten normálmente de la posición 18432 o de 16384). Y es curioso, hace cuestión de minutos, antes de entrar en el foro me pregunté a mí mismo por qué tiene que haber basura en la pantalla cuando se vuelca un juego con un transfer, si hubo o hay alguna manera de evitarlo.

Hasta pronto.

[miguel]

Y es curioso, hace cuestión de minutos, antes de entrar en el foro me pregunté a mí mismo por qué tiene que haber basura en la pantalla cuando se vuelca un juego con un transfer, si hubo o hay alguna manera de evitarlo

Esos aparatos salvan la totalidad de la memoria, por lo tanto en algún lugar hay que meter datos como estado de los registros en el momento actual de juego, código para cargar los bloques que se generan... Y que mejor sitio que la pantalla ya que el resto de la memoria seguramente se esté utilizando para código o datos del programa que queremos salvar.

[Ralphy]

Razón que tienes Miguel. No solo se salva el juego en sí sino el estado del mismo cuando comenzamos a grabar, o sea (casi siempre en) el menú de opciones, y eso ya serían mas datos a salvar. Muchas veces me he preguntado si habría algún modo de aprovechar alguna posición entre 0 y 16383. Lo más lógico es que si yo intentara un LOAD "PROHIB CODE 2" CODE 127,2048 habría errores en la carga (se me quedó colgado en varias ocasiones sobre todo con los PRINT USR) a menos que se las ingenie alguien para que esa posición la reconozca como la 32768 por poner un ejemplo sin dirigir la posición con LOAD CODE 32768 para evitar pisar los datos anteriores.

Hay juegos piratas donde la posición inicial del juego (no de la pantalla) es, como ejemplo, la 24576. Pues bien, el 2º bloque comienza en el mismo sitio incluso el 3er bloque igual, y luego jugamos perféctamente. El 2º bloque ni el 3º no pisan los datos anteriormente cargados, es como si hubiera montada una posición "virtual" sobre la posición 24576. Todo ello sin haber machacado el dibujo (lo mejor de todo es que lo que antes era multicarga ahora no lo es). Todo es posible, todo tiene sus ventajas e inconvenientes ya que los transfers nunca perdonan pero son muy útiles.

[miguel]

Muchas veces me he preguntado si habría algún modo de aprovechar alguna posición entre 0 y 16383.

No, no lo hay. Esa zona de memoria es la ROM (read only memory) Es una zona de solo lectura, donde está el sistema operativo del Spectrum, no se puede utilizar como almacenamiento temporal, como la RAM (a partir de 16384 hasta 65535)

Lo más lógico es que si yo intentara un LOAD "PROHIB CODE 2" CODE 127,2048 habría errores en la carga (se me quedó colgado en varias ocasiones sobre todo con los PRINT USR)

Lo más lógico es lo que hace xD

Por mucho que cargues en ese rango de direcciones, o hagas pokes, o lo que quieras, no vas a modificar las posiciones de memoria de la ROM. Y los PRINT USR a esas zonas pues si tienes suerte, y segun donde caigas, te devolverá el control del sistema, se colgará, te llenará la pantalla de colores, o hará lo que le rote.

De hecho hay algún juego que como método de protección tenía generado un bloque de datos superior al tamaño de la RAM (49152 bytes), y lo empezaba a cargar en la ROM...

Hay juegos piratas donde la posición inicial del juego (no de la pantalla) es, como ejemplo, la 24576. Pues bien, el 2º bloque comienza en el mismo sitio incluso el 3er bloque igual, y luego jugamos perféctamente. El 2º bloque ni el 3º no pisan los datos anteriormente cargados, es como si hubiera montada una posición "virtual" sobre la posición 24576. Todo ello sin haber machacado el dibujo (lo mejor de todo es que lo que antes era multicarga ahora no lo es). Todo es posible, todo tiene sus ventajas e inconvenientes ya que los transfers nunca perdonan pero son muy útiles.

Pues no me entero mucho de lo que dices. Pero que tu veas una cabecera de un bloque con una dirección, y que luego cargue ese bloque donde dice, puede que sea así, o puede que no. Puedes tener un bloque en que la cabecera diga que empieza en 26000 y luego con un simple LOAD""CODE 40000 lo cargamos en esta dirección. Por no meternos a hablar sobre los diferentes métodos de protección, de carga "customizadas"...

Y no creo que tenga que ver que sean piratas o bucaneros

Esto es un Spectrum, no hay posiciones "virtuales", a no ser que hablemos de los modelos 128k y la paginación de la memoria. Pero creo que no disparas por ahí.

[Ralphy]

Miguel escribió "Esto es un Spectrum, no hay posiciones "virtuales", a no ser que hablemos de los modelos 128k y la paginación de la memoria. Pero creo que no disparas por ahí."


Sí, hablaba del modelo 128k. Lo de las "posiciones virtuales" solo era una forma de hablar, una expresión.


Miguel escribió "Y no creo que tenga que ver que sean piratas o bucaneros."


Pues la verdad es que sí tiene que ver, ya que no son originales, son versiones desprotegidas donde se consiguió meter todo el programa y fases en solo dos o tres bloques (comprimidos) que cargan en la misma posición inicial sin pisarse. ¿ Curioso, verdad ? ¿ Como se explica que un bloque comienza en 25000, el 2º también en 25000, el 3º también en 25000 y al final cargue, en vez de "1er bloque 25000, 2º bloque 50000 y 3er bloque 75000 ? (Bueno, éste último es imposible jajajajaj)


Miguel escribió "De hecho hay algún juego que como método de protección tenía generado un bloque de datos superior al tamaño de la RAM (49152 bytes), y lo empezaba a cargar en la ROM..."


Hay un juego, el Back to school, cuyo bloque turbo ocupa unos 82000 bytes (no tiene cabecera y comienza con el dibujo) y claro, se sobrepasa del 65535 unos 16000 bytes. Lo más curioso es que rula bajo el 48k (será por la protección). Ese tipo de protección lo veo un absurdo, porque un turbo (x2) de 82000 bytes equivale a lo que tarda un bloque de carga normal de 41000 bytes que es lo que ocupa la gran mayoría de los juegos. De seguro que en 82000 bytes tienen que haber datos que no hacen falta para nada, y me juego a que si hacemos un volcado con el Hypraloader,el k7zx o incluso el transtape de ese juego no tenemos 82000 bytes sino 49152 a lo sumo y rAYAS en la pantALLAS.

CHAU.