Inicialización de memoria en 128 y compresión RLE

Sinclair QL, ZX81, +2, +3, 128K ...
Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 17 Jun 2020, 11:12

Hace ya varios días que amplié sna2transtape para hacer taps de snapshots de 128k. Al hacerlo, me volví a topar con una característica "particular" de los Spectrum 128k: no inicializan la memoria a cero. Además, hay una gran diferencia entre los 128k/+2 y los +2A/+3.

Veamos un poco el problema: un snapshot de 128k que copie toda la memoria tarda más de 12 minutos en cargar (esto varía según el número de ceros y unos... un snapshot con muchos ceros ocupa menos tiempo). Así que lo primero que hice fue implementar un algoritmo de recortes en mi conversor. Este algoritmo busca el primer y último byte que no sean cero dentro de una página, y copia solo los bytes entre ellos. Si toda la página está llena de bytes a cero, omite por completo la página (excepción: la página 5 se copia siempre completa). Resultado: aunque acorta sensiblemente el tiempo de carga, siempre copia bytes de más.

¿Por qué? Básicamente porque el Spectrum no inicializa toda la memoria a cero. O más bien, aunque la pone a ceros durante el test luego mete datos en ella. Esto no es nada nuevo (en un 48k, se inicializa el área de variables del BASIC, los UDG y se pone la pila al final de la RAM), y el transfer Phoenix lo contemplaba a la hora de implementar su política de recortes.

¿Qué datos mete en los 128k/+2?
- Al final de la RAM0, se encuentran la pila y los UDG (igualico que en los 48k).
- La RAM7 contiene algunos datos relacionados con el editor de 128k.

¿Y en los +2A/+3?
- La RAM7 contiene (además de los datos del editor) variables relacionadas con la unidad de disco.
- Las RAM1, 3, 4, y 6 contienen el RAMDisk, y son inicializadas con el valor $E5.

Esto afecta a mi algoritmo de recortes... siempre detecta los bytes usados en la RAM7, y en los +2A/+3 tiende a copiar toda la RAM. Valorándolo en tiempos de carga:
- Snapshot 48k: 4m 30s.
- Snapshot 128k sin recortes: >12m.
- Deflektor (48k): tarda en cargar 4m 55s (+2), 11m 56s (+3).
- Fairlight (128k): tarda en cargar 8m 06s (+2), 12m 19s (+3).
- Operation Wolf (128k): tarda en cargar 12m en todos los casos.
- Harrier Attack (16k): tarda en cargar 2m 07s (+2), 9m 47s (+3).

Deflektor representa a los programas de 48k, Fairlight es un programa de 128k que utiliza la RAM extra (sin exagerarlo), Operation Wolf utiliza prácticamente toda la RAM y Harrier attack es el extremo contrario: un programa de 16k cargado en un 128k.

Como curiosidad, hice un programa que borraba toda la RAM y luego cargaba el juego. En ese caso, los tiempos de carga fueron 4m 34s (Deflektor), 7m 45s (Fairlight), 12m (Operation Wolf) y 1m 47s (Harrier Attack). En el caso de borrar memoria se ahorran algunos segundos, pero la diferencia entre un 128k y un +3 es brutal.

¿Mi solución? Reinventar la rueda y hacer el algoritmo RLE número 3927 para Spectrum. En principio, mi rutina descompresora sería algo así:

Código: Seleccionar todo

INICIO:
  Leer byte alto contador
  Leer byte bajo contador
  Si byte alto y byte bajo <> 0
    Si byte alto < 128
      copiar tantos bytes como indique el contador
    sino
      resetear bit alto contador
      leer byte a repetir
      escribir contador veces byte
    finsi
  finmientras
volver a INICIO


En resumen: hay dos tipos de bloques. Si el bit de más peso del contador está a cero, se copian tantos bytes como se indica; si está a uno, se lee un byte y se repite tantas veces como se indique. Si nos encontramos con que el contador es cero, se acabaron los datos comprimidos.

Aquí veo dos ajustes a la rutina compresión:
- Si la página empieza por tres o menos bytes repetidos, no merece la pena codificarlos como bytes de repeticiones.
- Si detrás de un bloque de copia hay cinco o menos bytes repetidos, tampoco merece la pena codificarlos como tales.

La idea es tener un algoritmo sencillo y rápido (se tiene que ejecutar entre bloque y bloque en la cinta). Primero pensé usar contadores de 7 bits para ambos bloques, o usar uno de 7 bits para repeticiones y uno de 15 para copia, pero intuyo que es más eficiente usar dos de 15 bits. ¿Qué opináis? ¿Suena bien para implementarlo? ¿Modificaríais el tamaño de los contadores?

NOTA: Los tiempos de carga se han medido generando un fichero tap, convirtiéndolo en wav y mirando su longitud en audacious).

NOTA 2: Los snapshots se han realizado después de la carga, checksums y decodificaciones. Los breakpoints estaban puestos en las direcciones 42831 (Deflektor), 50389 (Fairlight), 41525 (Operation Wolf) y 30036 (Harrier Attack), y se han utilizado cintas con sus sistemas de protección (Alkatraz en Fairlight y Speedlock en Operation Wolf).

NOTA 3: Realmente sería mucho maś eficiente utilizar el zx7 para esto, pero tendría que mirar cómo implementar la rutina compresora dentro de mi programa.

NOTA 4: Tengo previsto que el conversor de sna a transtape siga utilizando el sistema de recortes. La idea es que si una página esté a cero, se elimine; si tiene datos, se comprima y se compare qué ocupa menos (recortada o RLE). Las excepciones serían la página 5 (siempre copia completa) y la 2 (siempre copia recortada).
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
Namek
Atari 1040 STf
Atari 1040 STf
Mensajes: 872
Registrado: 11 Jul 2011, 13:13
Gracias dadas: 21 veces
Gracias recibidas: 51 veces

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor Namek » 19 Jun 2020, 11:33

Antes de nada felicidades por la utilidad y personalmente creo que todo lo que no sea utilizar un compresor potente es perder el tiempo, y generar un snapshot de un juego de 48K o 16K cargado en 128K me parece un sacrilegio cuando es tan facil arracar en modo 48K en cualquier Spectrum, y de paso te aseguras de que el snapshot funciona en un 48K.

Saludos cordiales.

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 19 Jun 2020, 15:36

Bueno, hay varias cuestiones acerca de todo esto...

Empiezo por los snapshots de 16k, 48k y 128k. Me parecía interesante tener un snapshot de 48k como referencia para comparar, aunque hay casos en los que se cargan solo 48k para hacer uso de las habilidades de 128k (dos ejemplos relacionados: Exolon tiene música AY si se carga en modo 128k; Cybernoid tiene dos programas de 48 y 128k, aunque ninguno de los dos usa la paginación y solo se diferencian en el sistema de sonido). Otro caso interesante (para mis propósitos) es Humphrey, que lo miré en su día y tiene "huecos" por toda la memoria. El caso de Harrier Attack es ir directamente a un caso extremo... muchos juegos de 16k directamente no funcionan en un 128k.

Otro problema es que yo he fabricado snapshots para probar la utilidad (primero centrándome en diferentes modos de interrupción y registros I/R, luego he hecho unos cuantos para probar con páginas a medio usar y sin usar), pero la utilidad no puede elegir qué se le echa encima. En los snapshots que he descargado en internet he visto juegos de 48k etiquetados como 128k (y el snapshot hecho desde esa máquina), y también me he tropezado con snapshots de 128k que están hechos desde clones rusos.

El tema de la compresión tiene varios factores a tener en cuenta:
- Tiempo: cargo página por página, así que me debe dar tiempo a descomprimir una página entera entre bloque y bloque de cinta (en el emulador la cinta se detiene, pero en el mundo real la cinta seguirá corriendo mientras descomprimo). Realmente no me he puesto a medir tiempos, pero me ha puesto en alerta que dos juegos de los "casos dignos de estudio" (Deflektor y Grell and Fella) pasan varios segundos desencriptando/haciendo checksums/descomprimiendo datos después de terminar de cargar. Si la descompresión tarda mucho, corro el riesgo de que acabe después de que empiece el tono piloto del siguiente bloque.
- Sencillez: implementar la compresión RLE es (casi) trivial y el algoritmo de descompresión ocupa muy poco espacio. Todo esto tiene la ventaja de que puedo programarlo sin que se me salga el cerebro por las orejas (los algoritmos tipo LZ y Huffman me parecen magia negra).

La idea es reducir estos tiempos de carga exagerados por los snapshots de +3, y pasarlos a tiempos más normales. Históricamente, muchos transfers de 48k no comprimían datos, con la excepción de Phoenix (recorte de datos) y Multiface (compresión RLE). Probablemente esto sea porque el ahorro de tiempo en un 48k no merecía la pena... pero los 12 minutos de carga en un 128k sí que justifican complicarse la vida. Otra limitación es el espacio que tuvieran en la RAM/ROM del dispositivo, y el hecho de que el uso de la pila se ve penalizado con la corrupción de pantalla (he visto un snapshot de Multiface 128 que corrompía los tres tercios de la pantalla).

Lo primero que pensé fue en usar el zx7 que tantas buenas experiencias me ha dado. El problema es que, aunque tengo los fuentes, no veo claro cómo integrar eso en mi utilidad. Otros compresores... bueno, no he hecho ni mirarlos.

Esta mañana me he sentado para hacer el algoritmo de compresión en PC y descompresión en ensamblador de Z80. Como era de esperar, ninguno ha funcionado bien a la primera ;) pero ya está corregido (que no optimizado) y puedo integrarlo en mi programa y el cargador. Cuando lo tenga ya metido en mi programa, reharé todos los tap y a ver cuánto tiempo gano.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 21 Jun 2020, 20:19

Bueeeno... creo que ya he terminado (casi) con el tema de la compresión. Ahora me toca cazar dos bugs no relacionados y tendré lista la siguiente versión para la web.

Como curiosidad, ya preveía que mi algoritmo de compresión se prestaba a ciertas optimizaciones... pero lo que no preveía era el impacto tan negativo que tenía. La primera pruebas que hice fue la pantalla de menús del JetPac, y pasó de 6912 a 1511 bytes. Previsible (está llena de ceros), pero la gran sorpresa fue cuando probé con la pantalla de carga del Skool Daze... que pasó a 8254 bytes. Mal rollo.

Así que me puse a analizar lo que producía. Resulta que en el caso del Skool Daze, generaba 1821 bloques (791 copias, 1029 repeticiones), lo que significa que había 3642 bytes extras en datos para la descompresión :shock: Así que después de darle vueltas un par de días a cómo optimizarlo, ya he dado con la clave.

Las reglas de optimización que he empleado son las siguientes:
- Si un bloque RLE tiene 5 repeticiones o menos y le sigue uno de copia, lo cambio por uno de copia.
- Si dos bloques de copia están juntos, los uno en un único bloque.
- Si el último bloque está copiando ceros, lo suprimo.

Repitiendo estos pasos hasta que ya no se podían sustituir/fusionar más bloques, la pantalla del Skool Daze ha pasado a medir 6627 bytes (con solo 523 bloques). La del Jet Pac también reduce considerablemente su tamaño (hasta los 1307 bytes). Así que el algoritmo de compresión está bastante logrado y creo que se va a quedar tal y como está.

El programa de conversión ahora hace los siguientes procesos:
- Comprime la pantalla. Si ocupa menos de 6912 bytes, la graba comprimida; en caso contrario la graba sin comprimir.
- Por cada página excepto la 5, comprueba cuál es el primer y último byte usados.
- Por cada página excepto la 2, las comprime. Si los datos comprimidos ocupan menos que los bytes que están usados, graba la versión comprimida; si no, grabará la versión "recortada" (solo los bytes usados). Si una página está completamente vacía, no la graba a cinta (el programa cargador rellena la RAM a 0).
- Las páginas no procesadas son la 5 y la 2. En el caso de la 2, como se utiliza de buffer para la compresión, se graba la penúltima y solo puede estar recortada.
- Los últimos 9472 bytes de la RAM 5 no pueden estar ni recortados ni comprimidos (aquí tenemos la pila, el cargador y el descompresor).

¿Es esto algo que hubieramos podido ver en un transfer? Bueno, después de pensarlo un poco creo que no. El algoritmo de descompresión es rápido y no necesita casi RAM (debido a que no se usa en la RAM 5 ni la 2), pero otra cosa es el de compresión (mi implementación utiliza unos buffer bastante grantes). Incluso en el caso de no hacer la pasada de optimización, o el hipotético transfer tiene una buena cantidad de RAM o vamos a tener una buena cantidad de corrupción en pantalla.

¿Es este el algoritmo más eficiente? Pues tampoco. RLE es el algoritmo más básico y menos eficiente de todos los que hay, pero debido a que es el más básico también es el más probable que se hubiera visto en su día. Después de estudiarlo un poco, veo que zx7 se puede meter fácilmente (a costa de no entender ni papa de qué hace al comprimir y al descomprimir).

Por ahora, me conformo con este. En las pruebas que he hecho ha cumplido con mis espectativas, que se resumen en que:
- Sé lo que hace y por qué hace.
- Se notan mejoras en los tiempos de carga (en varios casos, baten los tiempos de carga originales).
- Los tiempos de carga de snapshots de +3 están muy cerca de los del +2. Los snapshots que no ocupan toda la RAM (p.ej.: Fairlight) no se tiran a los 12 minutos, sino que quedan en tiempos de carga más normalitos.

Como la curiosidad del día... Grell and Falla (Codemasters). Si tengo que hacer caso a lo que marca mi programa, usa casi todas la memoria de todas las páginas salvo la 7, y mi mejor tiempo de carga son 10m 36s. El juego original creo que combina carga turbo y compresión (tras cargar se tira varios segundos mangoneando por toda la RAM)... y logra cargar todo eso en menos de 5 minutos. Para quitarse el sombrero.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

¿Se me ha olvidado cómo se cuenta?

Mensajepor zup » 26 Jun 2020, 15:20

No he publicado todavía la nueva versión del sna2transtape porque parece que se me ha olvidado contar o algo parecido.

Básicamente estoy teniendo problemas con la optimización de mis datos comprimidos. Resumiendo un poco, mi compresor funciona en tres pasos:
- PASO 1: Genero una serie de contadores que almacenan series de bytes a copiar y series de bytes repetidos.
- PASO 2: Optimizo esos contadores.
- PASO 3: Escribo los contadores y los bytes como datos comprimidos.

Imaginemos la siguiente secuencia de bytes: 01 02 03 FF FF FF FF. En el paso uno, copiaría dos bloques de contadores, que se codifican como 00 03 y 80 04 (el bit de más peso es uno si es una repetición o 0 si es una copia). En el paso dos, se optimizan. En el paso tres la secuencia de datos sería convertida a 00 03 01 02 03 80 04 FF 00 00 (los dos bytes a cero señalan el fin de los datos comprimidos). Sencillo ¿verdad?

Ahora lo complicado y donde no entiendo qué está pasando, es la pasada de optimizaciones. Básicamente se dan tres optimizaciones:
- Si un bloque es de copia y le sigue un bloque de repetición de 3 o menos bytes, el bloque de copia se extiende para "absorber" el segundo bloque. Para visualizarlo gráficamente:
01 FF FF > 00 01 01 80 02 FF (sin optimizar, 6 bytes) > 00 03 01 FF FF (optimizado, 5 bytes)
- Si un bloque es de repetición de 3 o menos bytes y le sigue uno de copia, lo podemos convertir a uno de copia (extendido o sin extender). Esta es la situación inversa a la anterior:
FF FF 30 > 80 02 FF 00 01 30 (sin optimizar, 6 bytes) > 00 03 FF FF 30 (optimizado, 5 bytes)
- Si hay dos bloques de copia seguidos, se fusionan. Esta es una situación que no se puede dar inmediatamente después de hacer el paso 1, pero se puede dar en los pasos intermedios de optimización:
00 01 01 00 02 DE DD (sin optimizar, 7 bytes) > 00 03 01 DE DD (optimizado, 5 bytes)

El problema lo tengo en las dos primeras optimizaciones (la tercera funciona siempre como debe). Por accidente descubrí que si la regla dos la "ampliaba" a todos los bloques de repetición de 5 o menos bytes, los datos comprimidos ocupaban menos bytes (aunque el número de bloques fuera mayor que con 3 o menos bytes). No parece un bug sino algún tipo de error de planteamiento, ya que ambas ristras de datos comprimidos descomprimen igual.

Al no descubrir la razón, he hecho una "trampa"... he puesto un par de bucles en los que varía el mínimo de bytes necesarios (de 0 a 10) en las dos primeras reglas de compresión, y hace una pasada definitiva usando los mejores valores. Aunque con la broma tiene que hacer 101 pasadas de optimización (10*10 más la definitiva), gracias a los procesadores modernos no tarda demasiado y (según casos) ahorra 200 bytes.

Los valores "mágicos" parecen variar según bloques entre 0 y 5 (en algunos casos, tiene que ver con la NO presencia de bloques de una cierta longitud), pero no le veo la lógica a los resultados.

Ahora bien... ¿alguien sabe de qué va esto? Parece que esté pasando algo totalmente por alto, ya que aunque los valores previstos arrojan un resultado óptimo en cantidad de bloques, los resultados no óptimos arrojan ristras de bytes más pequeñas. ¿Alguna idea?

(En otro orden de cosas, también tengo por ahí una versión modificada que usa zx7 en vez de mi compresión RLE... obviamente zx7 está mucho más optimizada y hace taps mucho más rápidos de cargar, pero debería contactar con Einar Saukas para pedirle permiso y además tengo la sensación permanente de no tener ni idea de qué estoy modificando. Otra cuestión es que, por algún extraño motivo, mi programa tarda una cantidad considerable de tiempo en comprimir los datos con zx7... mucho más de lo que cabría esperar)
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
robcfg
Amiga 2500
Amiga 2500
Mensajes: 2092
Registrado: 07 May 2009, 15:34
Sistema Favorito: Amstrad CPC
primer_sistema: Atari 800XL/600XL
Ubicación: Estocolmo
Gracias dadas: 546 veces
Gracias recibidas: 132 veces

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor robcfg » 26 Jun 2020, 17:33

Me he hecho una tabla a ver que pasa:

Código: Seleccionar todo

Datos                       |  Normal             |  Regla 2 optimizada
----------------------------+---------------------+----------------------------------
FF FF FF FF FF FF FF FF 01  |  80 08 FF 00 01 01  |  00 09 FF FF FF FF FF FF FF FF 01
FF FF FF FF FF FF FF 01     |  80 07 FF 00 01 01  |  00 08 FF FF FF FF FF FF FF 01
FF FF FF FF FF FF 01        |  80 06 FF 00 01 01  |  00 07 FF FF FF FF FF FF 01
FF FF FF FF FF 01           |  80 05 FF 00 01 01  |  00 06 FF FF FF FF FF 01
FF FF FF FF 01              |  80 04 FF 00 01 01  |  00 05 FF FF FF FF 01
----------------------------+---------------------+----------------------------------
FF FF FF 01                 |  80 03 FF 00 01 01  |  00 04 FF FF FF 01
----------------------------+---------------------+----------------------------------
FF FF 01                    |  80 02 FF 00 01 01  |  00 03 FF FF 01
FF 01                       |  80 01 FF 00 01 01  |  00 02 FF 01


A la vista está que la optimización de la regla 2 (si lo he entendido bien) no debería servir para condiciones con repetición de más de 3 unidades.

Podrías poner una secuencia con la que suceda lo que describes y el resultado ?

Otra optimización, que lo mismo es interesante, sería tener la flag de copia o repetición en el mismo byte que el tamaño, de forma que a cambio de tener repeticiones o copias de un máximo 127 bytes, te ahorras un byte por cada bloque comprimido/

Es decir, en vez de 80 05 FF, poner 85 FF y enmascarar la flag o el número.

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 26 Jun 2020, 19:00

Es complicado de determinar. Tengo una función que analiza los contadores y me da la longitud de los datos comprimidos y la cantidad de bloques de cada tipo, pero lo que no tengo es una que busque ocurrencias extrañas.

Es decir, tengo la visión global de qué está pasando pero no los casos concretos en los que está pasando. Uno de los logs que producía esta función era de este tipo:

Código: Seleccionar todo

Longitud RLE (inicial)  :  1530 bytes,   351 bloques (  147 copia,   203 RLE)
Longitud RLE (temporal) :  1667 bytes,   351 bloques (  233 copia,   117 RLE)
Longitud RLE (temporal) :  1497 bytes,   265 bloques (  148 copia,   116 RLE)
Longitud RLE (temporal) :  1389 bytes,   211 bloques (   94 copia,   116 RLE)
Longitud RLE (temporal) :  1327 bytes,   180 bloques (   63 copia,   116 RLE)
Longitud RLE (temporal) :  1325 bytes,   179 bloques (   62 copia,   116 RLE)
Longitud RLE (temporal) :  1325 bytes,   179 bloques (   62 copia,   116 RLE)
Longitud RLE (final)    :  1325 bytes,   179 bloques (   62 copia,   116 RLE)
1325 bytes comprimidos


En cuanto a lo del flag y el tamaño, he escrito ejemplos pequeños (por no enmarañar la cosa) pero ahora mismo, tal cual está, el contador es de 15 bits y el flag es el de más peso (pero los tengo almacenados al revés, aunque tampoco hay razón para ello). Es decir, que podría haber una secuencia del tipo C0 00 E5 para describir 16384 bytes a E5 (que es como deja el +3 la RAM3 al iniciarse). Obviamente, la rutina está más optimizada a suprimir grandes bloques de repeticiones (por otra parte, tener un contador de 15 bits simplifica algunas rutinas).
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 27 Jun 2020, 20:05

He subido la versión 1.24 a mi blog. La compresión RLE está metida en el fichero rle.h y creo que lo siguiente que voy a hacer es variar un poco la estrategia de optimización a ver qué pasa.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!

Avatar de Usuario
zup
Amiga 2500
Amiga 2500
Mensajes: 2890
Registrado: 04 Sep 2009, 20:07
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Nintendo DS/3DS
Primera consola: Nintendo GameBoy
Ubicación: Navarra
Gracias dadas: 57 veces
Gracias recibidas: 243 veces
Contactar:

Re: Inicialización de memoria en 128 y compresión RLE

Mensajepor zup » 23 Jul 2020, 16:31

La cosa ha acabado en que, después de hacer montones de pruebas, no he encontrado razón para el comportamiento ¿anómalo? de esa rutina de compresión. Así que me he deshecho de la rutina RLE con contadores de 15 bits y la he sustituido por una con contadores de 7 bits que no necesita ningún tipo de optimización.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!


Volver a “Sinclair/Spectrum”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 7 invitados