Pruebas en Dragon

Avatar de Usuario
Chema
Mensajes: 1596
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 505 veces
Agradecimiento recibido: 205 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor Chema » 19 Feb 2015 13:14

Último mensaje de la página anterior:

Hola pere,

El 6502 es little-endian, en memoria el word $1234 se almacena en la dirección D el byte bajo ($34) y en la D+1 el byte alto ($12). El assembler se encarga de eso (al no ser que estés haciendo las cosas a mano). Para cargar el acumulador con el byte que está en la dirección $1234 se escribe lda $1234 en el fuente, quiero decir.

De todas formas mira a ver si merece la pena usarlo antes de nada (a mí me parece que podría ser, porque la ganancia no es insignificante, pero vamos como veáis). Usa un algoritmo LZ77, así que igual ya hay código para descomprimir en asm del Dragon.

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 13:50

Una prueba mas .... he juntado las 22 pantallas en un solo fichero y he comprimido el fichero resultante.
La ocupación inicial es la misma: 88.704 bytes
Comprimido (con FilePack): 55.162 bytes (38%)
Comprimido (con D-Zip): 59.977 bytes (32%)

En ninguno de los dos casos, no parece variar demasiado el porcentaje de compresión a pesar de aplicarlo a un fichero de 88k

saludos
pere

Avatar de Usuario
Chema
Mensajes: 1596
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 505 veces
Agradecimiento recibido: 205 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor Chema » 19 Feb 2015 13:52

Pues no hay tanta ganancia, no. En fin, supongo que las imágenes son bastante complejas (además de pequeñas). La diferencia se notará más si dispones de más espacio. Si en lugar de 88,7Kb tienes 100 igual ya no es una imagen más y si usas un disco de doble cara pues más...

De todas formas yo no me metería en el berenjenal al no ser que fuese determinante la diferencia, vamos.

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor luiscoco » 19 Feb 2015 14:35

Los Drives normales de coco son de una sola cara, claro siempre se puede usar otro disco o darle la vuelta al primero, practica que no recomiendo, también hay equipos que tienen unidades de doble cara o 3 1/4 que da 720k pero la mayoría no, ademas estas unidades solo trabajan con trucos u otro sistema operativo.
Yo me decantaría por un segundo disco.

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 16:15

Hola Luis,

yo estoy mal acostumbrado porqué con mis disqueteras de 3,5" utilizo discos de 180K (una cara) habitualmente, pero para casos de almacenaje grande uso doble cara (360K) e incluso los de 720k sin problemas.
Posiblemente podríamos tener las pantallas en un solo disco que habría que poner en lugar del que lleve el ejecutable y los datos ... ya iremos viendo sobre la marcha, hasta ahora solo tenemos el 24% del código Z-80 traducido

Ayer finalicé dos diagramas mas con las rutinas de Objetos, así que ya solo me quedan las Acciones (1400 líneas aprox) que seguro que se llevarán otros 2-3 diagramas mas.

Estoy haciendo los diagramas en papel y lápiz para ir verificando que no nos quedan párrafos (etiquetas) en el global Z-80 que no han sido copiados en alguno de los trozos en que
está dividido para convertirlo. Lo que pasa es que una vez hecho, no cuesta demasiado pasarlo a Word por si necesitara hacer algún cambio a posteriori

Saludos
pere

BlackHole
Mensajes: 722
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 1 vez
Agradecimiento recibido: 49 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 19 Feb 2015 16:57

pser1 escribió:ya convertí las 22 pantallas de localizaciones que tenemos y estos son los resultados:
Ocupación sin comprimir: 88.704 bytes
Comprimidos con DZip (Sixxie): 61.192 bytes (compresión del 31%). Ahorro: 27.512 bytes, cabrian 6,8 ficheros mas o sea 6 imágenes adicionales
Comprimidos con FilePack (6502): 56.668 (compresión del 36%). Ahorro: 32.036 bytes, cabrian 7,9 ficheros mas o sea 7 imágenes adicionales
Ambos están lejos de obtener el 50% de compresión deseado.

Hola, buenas.
Como no he seguido este proyecto, ¿es público el enlace a dichas 22 pantallas para poder hacer alguna prueba por mi cuenta?
Entiendo que 88704 es un múltiplo exacto de 22 y cada fichero sería de 4032 bytes.
¿Son en RAW o tienen cabecera que descartar? ¿Cuál sería el orden de los bytes de esos ficheros respecto a la resolución y profundidad de color?
Gracias.

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor luiscoco » 19 Feb 2015 17:04

Pser te dirá mejor, pero son pantallas directas en PMODE 4 que deberian ser de 6144 pero como la pantalla para la parte grafica es parcial quedan los graficos de 4032 bytes y son sin cabecera excepto los 9 bytes del sistema Dragon , la coco usa solo 5 bytes, y son en formato motorola HIGH-LOW , primero el byte de bas valor

BlackHole
Mensajes: 722
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 1 vez
Agradecimiento recibido: 49 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 19 Feb 2015 17:36

¿Y de dónde las puedo descargar?
Si es un bitmap de 2 colores, entiendo que cada byte serían 8 pixels. ¿No tiene el PMODE 4 una resolución de 256x192? Me sale que los gráficos serían de 256x126 (una cifra rara por otra parte, pues uno esperaría redondear a 128 verticales). ¿Cada 32 bytes definen una línea horizontal, seguidos de 32 bytes de la línea siguiente?

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 18:07

Hola,

las pantallas son bmp convertidos por José Luis directamente a PMODE4 de Dragon pero sin cabecera = 4032 bytes.
La cabecera estandar de Dragon son 9 bytes, mientras que CoCo añade 5 bytes por delante y otos 5 por detrás (1 más en total)

Adjunto un zip con las 22 pantallas tal cual.
Además adjunto otro con las pantallas con cabecera para poder verlas en Dragón
Usando XRoar basta con hacer Ctrl+L y seleccionar la imagen deseada.
Luego para verla desde el prompt de Basic:
PMODE4,1:SCREEN1,1:FORI=1TO1000:NEXT
para dar tiempo a verla
Cada imagen ocupa 126 lineas horizontales sobre 192 así que queda un trozo en la parte inferior que NO se carga

saludos
pere
Adjuntos
BIN - para Dragon con cabecera Dragon.zip
y estas CON cabecera de Dragon
(47.6 KiB) Descargado 54 veces
PM4 - de PC sin cabecera (originales).zip
Estas son SIN cabecera
(47.45 KiB) Descargado 46 veces

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 18:36

perdona, no aclaré su formato.
Es simple y llano, las imágenes son en blanco y negro así que cada byte contiene la información de ocho bits en horizontal en la pantalla (1=blanco, 0=negro)
32 bytes x 8 = 256 que es la resolución horizontal ...
126 filas x 32 = 4032 bytes del fichero entero

saludos
pere

BlackHole
Mensajes: 722
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 1 vez
Agradecimiento recibido: 49 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 19 Feb 2015 20:46

Pues he estado haciendo unas pequeñas pruebas con la biblioteca de compresión aPLib, que es la que suelo usar en mis producciones de Spectrum.

Las 22 pantallas comprimidas tal y como venían en el ZIP, sumadas quedan en 48129 bytes (compresión del 45.74%)
Pero si reordenamos cada pantalla en otro buffer de 4032 bytes de tal forma que queden 32 columnas de 126 bytes cada una, al comprimirse quedan en 39478 bytes !!! (compresión del 55.45%)

Código: Seleccionar todo

inbuffer = (unsigned char *) malloc(4032);
outbuffer = (unsigned char *) malloc(4032);
n = 0;
for (i = 0; i < 32; i++) {
    for (j = i; j < i+4032; j += 32) {
        outbuffer[n++] = inbuffer[j];
    }
}

Ahora bien, habría que programar una rutina descompresora de aPLib para Motorola 6809...

Existe incluso un compresor más potente llamado Exomizer (muy utilizado en el mundo Commodore 64) que deja estas últimas pantallas reordenadas en solo 37996 bytes (compresión del 57.17%)
Aunque la descompresión es más lenta y compleja, ya existe rutina para 6809 programada por la demoscene del Thomson M05 y solo tendríais que adaptarla.

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 22:41

Hola,

Me he descargado el compresor y lo he ejecutado con Hob01.pm4 y con Hob25.pm4 (uno difícil y el más fácil)
Los resultados son:
Hob01.pm4 se comprime a 2.387 bytes (41%)
Hob25.pm4 se comprime a 1.542 bytes (61%)

La alternativa de reordenar los datos de otra forma ... entiendo que implica poner en fila las 126 bytes de cada columna, pero esto implicaría luego dos conversiones a partir del fichero comprimido.
En primer lugar descomprimirla con lo que obtendríamos la pantalla girada y luego habría que reorganizarla en otra área de pantalla.
El problema es que dentro del juego, debido a la gran ocupación de espacio por parte del código y los datos, solamente queda libre espacio para tener una pantalla gráfica y en ella están los textos entrados por el usuario que NO hay que romper al cargar la pantalla de la ubicación, compicado en cantidad!
Así pues, ciñéndonos a la pantalla tal cual está en Dragón, con aPack se ganaría bastante espacio, pero nos queda el tema del descompresor (debería ser corto y rápido)
El de Sixxie requiere solo 52 bytes y es instantáneo!
Si todo lo que tenemos es el DePack (en lenguaje C) me parece mucho trabajo a menos que alguien tome este tema y siga con el ... alguien se apunta?

saludos
pere

jltursan
Mensajes: 1931
Registrado: 20 Sep 2011 13:59
Agradecido : 57 veces
Agradecimiento recibido: 149 veces

Re: Pruebas en Dragon

Mensajepor jltursan » 19 Feb 2015 22:52

Efectivamente el Exomizer 2 es muy potente y es cierto que ya tiene descompresor 6809. Doy por hecho que la adaptación sería mínima, no creo que se use ninguna característica propia de ningun hardware, debe ser 6809 puro:

Código: Seleccionar todo

; Exomizer2 algorithm, backward with litterals for 6809
; by Fool-DupleX, PrehisTO and Sam from PULS (www.pulsdemos.com)
;
; This routine decrunches data compressed with Exomizer2 in raw mode,
; backward with litterals.
; This routine was developed and tested on a Thomson MO5 in July 2011.

   
; The Exomizer2 decruncher starts here.
; call with a JSR exo2 or equivalent.
;
; Input    : U = pointer to end of compressed data
;            Y = pointer to end of output buffer
; Output   : Y = pointer to first byte of decompressed data
; Modifies : Y.
;
; All registers are preserved except Y.
; This code self modifies and cannot be run in ROM.
; This code must be contained within a single page (makes use of DP), but may
; be located anywhere in RAM.

exo2    pshs    u,y,x,dp,d,cc           ; Save context
        tfr     pc,d                    ; Set direct page
        tfr     a,dp
        leay    biba,pcr                ; Set ptr to bits and base table
        clrb
        stb     <bitbuf+1               ; Init bit buffer

nxt     clra
        pshs    a,b
        bitb    #$0f                    ; if (i&15==0)
        bne     skp
        ldx     #$0001                  ; b2 = 1
skp     ldb     #4                      ; Fetch 4 bits
        bsr     getbits
        stb     ,y+                     ; bits[i] = b1
        comb                            ; CC=1
roll    rol     ,s
        rola
        incb
        bmi     roll
        ldb     ,s         
        stx     ,y++                    ; base[i] = b2
        leax    d,x                     ; b2 += accu1
        puls    a,b
        incb   
        cmpb    #52                     ; 52 times ?
        bne     nxt
   
go      ldy     6,s                     ; Y = ptr to output
mloop   ldb     #1                      ; for(;;)
        bsr     getbits                 ; Fetch 1 bit
        bne     cpy                     ; is 1 ?
        stb     <idx+1                  ; B always 0 here
        fcb     $8c                     ; (CMPX) to skip first iteration
rbl     inc     <idx+1                  ; Compute index
        incb
        bsr     getbits
        beq     rbl

idx     ldb     #$00                    ; Self-modified code
        cmpb    #$10                    ; index = 16 ?
        beq     endr
        blo     coffs                   ; index < 16 ?
        decb                            ; index = 17
        bsr     getbits                 ; Get size

cpy     tfr     d,x                     ; Copy litteral
cpyl    lda     ,-u
        sta     ,-y
        leax    -1,x
        bne     cpyl
        bra     mloop

coffs   bsr     cook                    ; Compute length
        pshs    d
        leax    <tab1,pcr
        cmpd    #$03
        bhs     scof
        abx
scof    bsr     getbix
        addb    3,x
        bsr     cook
        std     <offs+2
        puls    x

cpy2    leay    -1,y                    ; Copy non litteral
offs    lda     $1234,y                 ; Self-modified code
        sta     ,y
        leax    -1,x
        bne     cpy2
        bra     mloop

endr    sty     6,s                     ; End
        puls    cc,d,dp,x,y,u,pc        ; Restore context and set Y

; getbits  : get 0 to 16 bits from input stream
; Input    : B = bit count, U points to input buffer
; Output   : D = bits
; Modifies : D,U.

getbix  ldb     ,x
getbits clr     ,-s                     ; Clear local bits
        clr     ,-s         
bitbuf  lda     #$12                    ; Self-modified code
        bra     get3
get1    lda     ,-u
get2    rora
        beq     get1                    ; Bit buffer = 1 ?
        rol     1,s
        rol     ,s
get3    decb
        bpl     get2
        sta     <bitbuf+1               ; Save buffer
        ldd     ,s++
        rts                             ; Retrieve bits and return
   
; cook     : computes base[index] + readbits(&in, bits[index])
; Input    : B = index
; Output   : D = base[index] + readbits(&in, bits[index])
; Modifies : D,X,U.

cook    leax    biba,pcr
        abx                             ; bits+base = 3 bytes
        aslb                            ; times 2
        abx
        bsr     getbix                  ; fetch base[index] and read bits
        addd    1,x                     ; add base[index]
        rts

; Values used in the switch (index)   
tab1    fcb     4,2,4
        fcb     16,48,32

biba    rmb     156                     ; Bits and base are interleaved


He probado a comprimir ambos archivos y los resultados han sido (con las opciones por defecto en modo raw):

Hob01.pm4: 2127 bytes (48%)
Hob25.pm4: 1360 bytes (67%)

No parece que esté mal...

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 19 Feb 2015 23:27

Hola,
otro intento mas ... he descargado exomizer2 y lo he probado con los dos mismos ficheros
Estos son los resultados de los cuatro compresores probados:
Fichero Hob01.pm4 original 4032 bytes (uno complicado)
compresor de Sixxie: 3.031 bytes (25%)
compresor OSDK: 2.693 bytes (33%)
compresor aPack: 2.387 bytes (41%)
compresor exomizer: 2.127 bytes (47%)

Fichero Hob25.pm4 original 4032 bytes (el mas simple)
compresor de Sixxie: 1.790 bytes (55%)
compresor OSDK: 1.691 bytes (58%)
compresor aPack:1.542 bytes (61%)
compresor exomizer: 1.360 bytes (66%)

Exomizer es aproximadamente un 5% mas eficiente que el anterior aPack, si además el descompresor existe para 6809, se merece un experimento
Habrá que ver cuanto ocupa al compilarlo y que celeridad muestra ...
Veo que existe el fuente para 6809, es largo y además gasta una área de trabajo de 156 bytes a sumar a los posibles 150 bytes que puede ocupar una vez compilado, esto suma unos 300 bytes
pero en fin bien empleados estarán si comprime al 50% de promedio!
Ya os contaré como funciona el descompresor ...

saludos
pere

Avatar de Usuario
Chema
Mensajes: 1596
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 505 veces
Agradecimiento recibido: 205 veces
Contactar:

Re: Pruebas en Dragon

Mensajepor Chema » 20 Feb 2015 11:33

Esto ya es otra cosa... Habría que ver el rendimiento del descompresor, pero si va medianamente bien la cosa tiene buena pinta.

Avatar de Usuario
pser1
Mensajes: 2015
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 184 veces

Re: Pruebas en Dragon

Mensajepor pser1 » 20 Feb 2015 13:15

De momento NO va -banghead
Tengo la imagen Hob01.bin preparada
He compilado el fuente 6809 que viene en el zip de Exomizer2 con LWASM y con asm6809 por comparar el resultado. Es obviamente el mismo.
Los he copiado en un disco para probar en XRoar y fracasa estrepitosamente, a diferencia del descompresor de Sixxie que funciona perfectamente.
Si puedo me lo revisaré este fin de semana y subiré un VDK con lo necesario para hacer pruebas, tanto si funciona como si sigue fallando, por si alguien
quiere / puede dedicarle un rato. De hecho nos iría muy bien este factor de compresión que permite Exomizer2
El programa requiere 365 bytes (156 de datos) aunque no tengo claro si no ocupa mas (por el final) si le hacen falta ... el algoritmo para mi es sánscrito puro!
Además por hacerlo mas rápido usa DP y se automodifica, olé!
Como imagino que este texto:
; This routine decrunches data compressed with Exomizer2 in raw mode, backward
; with litterals.
hay que interpretarlo como que descomprime desde el final hacia el principio, cargo la pantalla en $C00 para que pueda ir moviendo del final de fichero al destino ($1BBF) sin pisarse.
Justo lo contrario que con el de Sixxie, que empieza por el principio, así que en aquel caso la pantalla la cargaba tan abajo como era posible (alineando final de fichero con final de zona de pantalla)
y la descompresión funcionaba bien.

saludos
pere

Pd. si alguien tiene posibilidades de echarle una ojeada este finde, solo tenéis que comentarlo y os subo todo lo necesario ... -nb

BlackHole
Mensajes: 722
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 1 vez
Agradecimiento recibido: 49 veces

Re: Pruebas en Dragon

Mensajepor BlackHole » 20 Feb 2015 13:42

Yo no entiendo ASM 6809. Y fíjate que conozco 68000, 6502 y Z80, pero el 6809 me parece críptico.
Tengo demasiados frentes abiertos como para coger la enciclopedia Mi Computer y ponerme a estudiarlo ahora.
Es posible que esa rutina no sea capaz de hacer una descompresión "in place". ¿Has probado a descomprimir a otra área de memoria que no se superponga?


Volver a “Proyecto The Hobbit 6809 por pser1”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado