EDITO: Solucionado - El problema era que tenía mal configurado el cargador (loader.bas)
Buenas, acabo de darme cuenta que al cambiar al modo 128K un par de pantallas se descomprimen corruptas llegando en ocasiones a resetear el spectrum.
Al ser siempre en las 3 mismas pantallas descartaría problemas de descompresión en sí y tampoco del buffer. De hecho lo que he probado a sido la siguiente linea a compress.h al final de la función descomprimir_map $this->bbcode_second_pass_code('', 'ret
.map1 BINARY "mapa_comprimido.bin //<---"
.map BINARY "mapa_comprimido.bin"')para desplazar el binario del mapa comprimido dentro del binario del juego principal y el problema ya no sucede.
Así que lo que parece es que algo sobreescribe parte del mapa (o de los streams) durante la compilación (es esto posible siquiera?) o en tiempo de ejecución ¿no? ¿Qué puede estar ocurriendo? Las pantallas son la 45, 46 y 47 (NO son las últimas del mapa, y las siguientes en adelante también se ven correctamente). Además como digo el único cambio al pasar del modo 48k a 128k ha sido para un test (libre de otros posibles fallos) donde he activado #define MODE_128K (y los respectivos cambios minimos).
el mapa_comprimido ocupa 1821 bytes (por si sirviera de algo)
Solucionado - Problemas compresión de mapas al pasar a 128K
Moderador: na_th_an
Solucionado - Problemas compresión de mapas al pasar a 128K
Última edición por elborra el Lun, 10 Mar 2014, 18:39, editado 2 veces en total.
Re: Problemas con compresión de mapas al pasar a 128K
Es muy probable que sea la pila que se mete en el buffer de descompresión. Hay que tener en cuenta que hay que mover la pila a un sitio seguro. Originalmente tiene su propio lugar en la parte alta de la RAM, pero en modo 128K esta RAM es la que cambia al paginar, por lo que hay que moverla más abajo. En el caso de la Churrera, la pila se coloca justo por debajo del binario, o sea, empieza en 24199 y crece hacia abajo. Es posible que haya alguna colisión de datos.
Aún no he tenido tiempo de estudiar la modificación de Antonio para comprimir mapas y no te puedo ser de más ayuda
Aún no he tenido tiempo de estudiar la modificación de Antonio para comprimir mapas y no te puedo ser de más ayuda
Como diría Rorshach: "Urm..."
Re: Problemas con compresión de mapas al pasar a 128K
Umm, si la pila crece hacia abajo y empieza justo antes del binario no deberia de afectar a una estructura creada dentro del código, ¿no?.
En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)
Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo
En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)
Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo
Re: Problemas con compresión de mapas al pasar a 128K
$this->bbcode_second_pass_quote('elborra', 'U')mm, si la pila crece hacia abajo y empieza justo antes del binario no deberia de afectar a una estructura creada dentro del código, ¿no?.
En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)
Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo
En mi caso el mapa comrimido empieza en la posicion 642 (decimal) del binario principal (el que sería churromain.bin)
Seguiré probando a cambiar cosas al medio tun tun XD a ver que resultados obtengo
No tiene por qué. Puedes crear una estructura donde quieras, y me suena que la rutina descompresora usaba un buffer en la parte más baja de la memoria.
Como diría Rorshach: "Urm..."