Mojonia 3.0

Sí, me refiero que esta dentro de lo que se supone que se compila. Que no es que la pila esté sobrescribiendo un buffer externo, es que hay algo escribiendo donde no debe.

Bueno, al final probando, probando, me he dado cuenta (inútil de mi) que los 45 bytes diferentes no son más que el contenido de reubica.bin. Es decir que el problema es que reubica.bin machaca parte del binario principal.

Yo he usado básicamente el make.bat de la carpeta spare (ejemplo goku mal) donde tenemos $this->bbcode_second_pass_code('', 'echo -------------------------------------------------------------------------------
echo ### CONSTRUYENDO CINTA ###
..\utils\bas2tap -a10 -sLOADER loader.bas loader.tap
..\utils\bin2tap -o reubica.tap -a 25000 reubica.bin
..\utils\bin2tap -o ram1.tap -a 32768 ram1.bin
..\utils\bin2tap -o ram3.tap -a 32768 ram3.bin
..\utils\bin2tap -o ram4.tap -a 32768 ram4.bin
..\utils\bin2tap -o ram6.tap -a 32768 ram6.bin
..\utils\bin2tap -o screen.tap -a 16384 loading.bin
..\utils\bin2tap -o main.tap -a 24200 gokumal.bin
copy /b loader.tap + screen.tap + reubica.tap + ram1.tap + ram3.tap + ram4.tap + ram6.tap + main.tap gokumal.tap
echo -------------------------------------------------------------------------------')
reubica se coloca en la dirección 25000, que al final resulta ser la dirección de los bytes sobreescritos del mapa en el fichero churromain.bin (la 61A8)....

El fichero reubica.asm no lo toqué del original, lo que si cambié fue el 128k.h a $this->bbcode_second_pass_code('', 'void SetRAMBank(void) {
#asm
.SetRAMBank
ld a, 16
or b
ld bc, $7ffd
out (C), a
#endasm
}')

En make.bat realmente se ve este "fallo" a simple vista (si es que lo es... yo siempre desde mi desconocimiento) pero eso de:
..\utils\bin2tap -o reubica.tap -a 25000 reubica.bin y ..\utils\bin2tap -o main.tap -a 24200 gokumal.bin estamos metiendo precisamente reubica dentro de parte del main (lo que no se es como no casca goku mal ¿? y por eso no le habia hechado cuentas)

En definitiva, una posible solución sería desplazar el binario principal del juego de 24200 a 25048 (por poner) y cambiar make.bat y el loader. Que no se si es la unica, o la mejor forma. Como creo haber detectado el fallo (ahora probaré si lo que propongo como solución corrige el error) ya no subiré el test con dogmole.

Um Qué raro.

No puedo mirar con detalle, pero lo suyo es cargar el bloque de juego AL FINAL, para que sobrescriba todo, reubica.bin incluido. O sea, no pasa nada si hay solapamiento. Reubica se utiliza solo durante la carga. Se coloca en 25000 y se ejecuta tras cada bloque de RAM extra para moverlo a su sitio. Luego se carga el binario del juego, que lo sobrescribe todo.

Algo raro tienes que estar haciendo para que reubica termine SOBRE el binario del juego. No tiene sentido, debería estar sobrescrito.

$this->bbcode_second_pass_quote('na_th_an', 'A')lgo raro tienes que estar haciendo para que reubica termine SOBRE el binario del juego. No tiene sentido, debería estar sobrescrito.

Sigo por aquí por no saturar y por llevar relación con el nombre del hilo.

Bien, una vez todo funcionando en modo128K y mapas comprimidos he vuelto a poner lo que yo pensaba necesario para mover el mapa_comprimido.bin a memoria extra y poder usar varios mapas comprimidos con tmxcompress.

El problema que me surge es la integración de las funciones get_resource (unsigned char res, unsigned int dest) de la churrera y descomprimir_map( unsigned char pantalla) de antonio. No debería de ser nada complicado pero me pierdo con la nomenclatura. Paso a resumir lo que me haria falta (na_th_an, verás que es un proceso muy similar al que usais para los compressed_levels):

La función de antonio en la parte en ensamblador$this->bbcode_second_pass_code('', ' and a
ld b, h
ld c, h
ld de, map <----- Esta línea
ld hl, fin-1
...
...
...
.map BINARY "mapa_comprimido.bin" <--- y esta otra')carga en el registro de la direccón de memoria donde comienza el binario (con esto ya es suficiente para que gestione que pantalla descomprimir). Obviamente el mapa ya no lo queremos en el binario principal con lo que esa última línea iría fuera.

El tema es ahora descomprimir el mapa_comprimidoc.bin en una dirección fija - notese la "c" ya que aparte de estar comprimido previamento con tmxcompress hay que pasarle apack para el proceso de librarian.exe- con get_resource (unsigned char res, unsigned int dest). En mi caso el mapa el el recurso 27.

Tal y como se hace con los compressed_levels (intentando copiar) defino una variable con un tamaño de 2000 bytes (partiendo de la base de que ningun mapa ocupe descomprimido con depack más de 2000 bytes, es decir que los mapas generados por la utilidad de antonio ocupen siempre menos que esa cifra). Esto lo hago así:
$this->bbcode_second_pass_code('', 'extern unsigned char mimapa;
#asm
.mimapa defs 2000
#endasm')Luego en la rutina de antonio cambio ld de, map por ld de, mimapa. Sin embargo al hacer la llamada a get_resource(27, (unsigned int) (mimapa) )ya empieza a dar problemas de compilación. Está claro que otra vez estoy mezclando punteros con arrays o cosas que no debería. A ver si me podeis echar una mano.

Mañana lo leo más despacio, que ahora tengo mucho sueño, y te digo algo

No es necesario que vuelvas a comprimir con apack los mapas, ya están comprimidos con tmxcompress. Es muy probable que el stream comprimido resultante ocupe más que el stream sin comprimir por el apack, vamos que es contraproducente.

En resumen, sáltate en este paso la compresión. Supongo que tienes todo el nivel en una estructura de datos, pues separa dicha estructura en dos partes: mapa por un lado y todo lo demás por otro, aplica compresión a lo otro y lo concatenas al mapa. La clave está en no comprimir dos veces lo mismo.