Karoshi MSX Community

A ver, que esto me tiene loco...

Todos tenemos claro como funciona un mapper; según el tipo de este tendremos páginas de 8K o 16K (el número de páginas dependerá del tamaño del megarom) que podremos intercambiar libremente en determinadas áreas de memoria simplemente pokeando el número de la página que queremos en una dirección determinada al uso dentro de cada una de esas áreas. Eso es a nivel lógico y todo parece sencillo; pero bien, lo que no tengo tan claro es como se organiza la ROM físicamente y me refiero a como están dispuestas esas páginas en el mismisimo archivo ROM. Ya se que con herramientas como el asMSX podría despreocuparme de ello; pero me gustaría conocer el intringulis del asunto.
Lo primero que se me ocurre es que por ejemplo, en un Konami 4 (no SCC) irá primero el rango "básico" $4000-$BFFF y luego concatenadas sin más las páginas del megarom, la 0, la 1, etc. ¿alquien tiene idea?.

Y para Nerlaska : ¿El MH que tipo de mapper usaba?

Pues yo usaba el Konami5 (el de SCC) y sencillamente era...

Un MEGAROM KONAMI5 es una CABECERA DE 16 Bytes + una serie de páginas de 8Kb dispuestas una detrás de otra
PAGE 0 hasta PAGE 255 ... páginas de 8 Kb, ok? Una detrás de otra.

COMO ORGANIZO EL MAPEADO EN LA MEMORIA PRINCIPAL, VAMOS LO QUE VE EL Z80:

PAGE 0: 0x4000
PAGE 1: 0x6000
PAGE 2: 0x8000
Yo utilizaba estas 24Kb para el motor principal (VDP, PSG, Compresión, PT3, etc.) y para el motor genérico del juego (gestión de actores, mapa, etc.)

PAGE 3: 0xA000 (Miscellánea)
Estas ultimas 8Kb las usaba para paginar el resto de cosas (gráficos, textos, scripts de actores, etc.)

El trabajar así me permitia trabajar de una manera bastante cómoda. Disponia de todo lo que necesitaba siempre que no me ocupara más de 8Kb. Sinceramente nada me ha llegado a ocupar más de 8Kb la verdad.
Podia "subir" cualquier gráfico o música o código a dicha página y luego usarlo desde el motor.

Como gestionaba todo esto desde SDCC? .. bueno .. me toco sufrir un poco :) .. acaba contruyendo una herramienta en la que creaba unos archivos TXT en plan lista de recursos que queria incluir en mi MEGAROM (gráficos, música, etc.) a estos recursos les asocio unas etiquetas. Estos recursos también podia ser código C compilado. La cuestión .. eso me generaba el MEGAROM y un .H de C donde tenia para cada etiqueta su posición exacta en el MEGAROM (page y address). El como incluia también  código compilado en este plan .. otro martirio :) .. porque tocada desensamblar y buscar los CALL que no llamaban al motor genérico para tenerlos localizados y poder cambiarlos a la PAGE 0xA000 a la hora de meterlos en el MEGAROM (esto era otra herramienta que me toco crear para automatizar).

Sinceramente el único problema que llegué a tener fué el de que los grupos de funciones que están dentro de la misma PAGE no supere el total de 8Kb. Hubo momentos que me toco hacer movidas y tal .. bueno .. basicamente optimizar el tamaño para poder tener ciertas funciones operando en la misma PAGINA. Por lo demás .. el funcionamiento era muy cómodo.

Espero que esto te haya servido J.L.

¡Muchas gracias!, ya lo creo que me sirve ;)

En principio lo que ya tenía pensado es exactamente el modelo que utilizaste, las tres primeras páginas para código y la última para el intercambio de datos. En mi caso únicamente serán gráficos comprimidos con un direccionamiento idéntico al que comentas, página + dirección dentro de la misma, esto no debería ser nigún problema, el problema lo voy a tener al tratar de encajar todo el código y datos (son muchos y por comodidad me interesa tenerlos siempre visibles) en los primeros 24KB, es pronto todavía para asegurarlo; pero voy a ir muy justo. Algunas librerias del SDCC me son imprescindibles si no quiero multiplicar por dos mi curro :( y las jodias se llevan un buen puñado de KBs por la cara.

Con la información que me has comentado voy a tratar de hacer un megarom simulado de 128KB concatenando una ROM de 24KB y luego 13 bloques de 8KB a pelo. En los 24KB de código voy a intercambiar las páginas y usar su contenido a ver si funciona todo como es debido.

J.L. al menos yo en el MH pase de usar nada del SDCC, de las librerias me refiero.
Utilice mis propias rutinas de multiplicación y división. Porque? ... una porque dejar que el SDCC se linke y coloque donde el quiera no me gusta y no me servia y la otra porque lo que tu dices .. nunca llegas a controlar el tamaño del código .. pero ya te digo .. para mi lo más importante es poder controlar DONDE ubicarlo.

Con 24Kb de código .. caben una barbaridad de cosas .. pero cierto es que sufri los martirios para poder meter lo que hay metido en el MH :)
No se que juego será el que tienes entre manos pero ... sea como sea .. animo! :)

Yo en estos momentos me estaba planteando hacer un proyecto desde cero .. gráficos y música incluidos .. por lo menos para participar en la Dev con algo .. pero ya veremos .. son demasiadas cosas .. el viejo es mi ídolo!!! :)

En este caso salvo completa desesperacion mantendré el núcleo de impresión, que como ya he dicho me ahorro un buen trabajillo. Por cierto, el megarom ya está chutando fino, ¡gracias otra vez! ;)

De eso de que "ya veremos" nada de nada, eh? (nerlaska -> :D :whip: <- viejo_archivero)


Pero, ¿se puede saber que te traes entre manos, malandrin? :guitar:

Pues todavía no se que va a salir, hay demasiados factores nuevos; pero bueno, poco a poco algo se va viendo... :)

Pues si Viejo .. ya veremos .. para mi es una gran puñeta .. pero es que no tengo tiempo de hacerlo todo .. al menos ya este año no :(
Y mira que me joroba no poder entregar juego a la Dev .. en fin .. Rezo porque obre un milagro! :)

Bueno, a lo mejor con algo pequeñajo ya vale ;). Creo que nos estamos acostumbrando todos demasiado a los megaroms... ;D

Pues nada, nerlaska, que no pasa nada hombre. Eso sí, mantendré los dedos cruzados para ver si se obra el milagro.  ;)

Yo digamos que ahun no me acostumbre.
Que haya heroes como vosotros en el 2007 que sigan programando estas perlitas para MSX le hacen saltar las lagrimas a mas de uno.
Personalmente que sean megaroms o no es lo de menos, serà que no nos seguimos pegando vicios a muchos 8k!
Venga, animo campeones que yo os tengo puesta una velita  ;D

Bueno.. cierto socio ha despertado de su letargo .. igual podremos participar con alguna cosa en la Dev!!! Power up!

¡Ugh!, ya tengo cifras y no son buenas, 35KB el código completo  :'(. Tengo que buscar la manera de reducirlo a 24K como sea, para empezar, la inicialización de globales es monstruosa, habrá que buscar otro sistema.

¿¿35 KB de código??. ¿No es eso demasiado, jl? :o :o :o

Que bien te lo vas a pasar J.L .. jejejeje ... no veas lo que sufrí en su día con el MonsterHunter :)
Por cierto Viejo .. seguro que hay juego para la Dev .. we are work in progress!!! SIIIIIIIII!!! No será un super megarom pero bueno .. al menos presentaremos algo.

Aun siendo código+datos, es demasiado, ya lo creo... :'(.
Si hubiesen sido 4 ó 5 KB; pero ¿11KB?, ¿como voy a recortar 11KB?. Tengo algunas ideas; pero esto va a ser jodido >:(

Recuerda que para esta edición tienes mucha RAM disponible, aunque probablemente estará siendo usada, ¿verdad?

Piensa en un conmutador de ROM<->RAM para escribir/leer en la RAM que está por debajo de la ROM en uso. Hay 64 KB listas para ser usadas ;)

Pues podría ser una solución, veamos...

El programa original ocupa compilado el rango $0100-$8CFF (más o menos). En el megarom, si me quito de enmedio la BIOS y activo la RAM en la página 0, podría tener lo siguiente:

0000 ----------------------------------------------------------------

         RAM

4000 ----------------------------------------------------------------
         Banco 1: página 0 (este banco se conmutara con la P4)
6000 ----------------------------------------------------------------
         Banco 2: página 1 (este banco se conmutara con la P5)
8000 ----------------------------------------------------------------
         Banco 3: página 2 (el banco permanece constante)
A000 ----------------------------------------------------------------
         Banco 4: página 3 (el banco permanece constante hasta que arranque el programa)
C000 ----------------------------------------------------------------

En B1:P0 inicialmente iría un arranque "ad-hoc" con la marca de ROM y un código de descompresión de los datos contenidos en el resto de B1:P0 y B2:P1, ese bloque se descomprimiría en la RAM de $0100-$3FFF. Hecho esto me podría quitar de enmedio ya B1:P0 y B2:P1 y conmutar por ejemplo a B1:P4 y B2:P5 que contendrían los fragmentos originales del código (nota para mi mismo: el código de descompresión+conmutación debería ejecutarse fuera de B1:P0 para evitar cuelgues malignos). Tras todas estas operaciones ya debería tener desde $0100 a $8CFF el código original y ya podría lanzar su ejecución. Pierdo dos página extras en el megarom; pero bueno, podría valer la pena.

No se si me he explicado.... :P

 :D :D :D :D :D :D :god: :god: :god: :god: :god: :god: