Karoshi MSX Community

Ya tengo otra duda que preguntar. A ver si me empapo de vuestra sabiduría y algún día puedo hacer alguna aportación interesante, en forma de juego espero  8)
Nada, que andaba yo todo ilusionado con la idea de meter mi juego en una ROM de 32KB, sobretodo porque eso facilita mucho las cosas: las primeras 16KB con la BIOS, las 32 siguientes con mi código y las 16 finales, RAM para variables y tal. El tema está en que ahora mismo veo que mi plan inicial era muy complejo y, o bien recorto un poco el juego, o en 32KB no me cabe.

Mi pregunta es la siguiente: es complicado adaptar un código que supone la estructura de memoria anterior a uno que tenga 48KB de ROM y use la RAM de otro slot, haciendo cambios de slot para cada acceso a RAM? Ralentiza mucho el sistema? Otra opción que veo es no tener las primeras 16KB ocupadas por la BIOS. Se ralentiza mucho (es más, se puede hacer?) cambiar de slot cada vez que se quiera acceder a la BIOS? Bueno, en general mi pregunta va en el sentido de que opciones tengo para pasar de 32 a 48KB teniendo en cuenta que necesito la BIOS y que, obviamente, necesito RAM?

Por otro lado, a mi me hace mucha ilusión tener mi juego en cartucho, y la oferta de Matra me gusta... sabéis si está limitada a ROMs de 32KB o pueden ser de 48KB? Es curiosidad, si no, eso puedo preguntarselo a ellos.

Pues ojala veamos alguno en un futuro :) Las roms de Matra van hasta los 64ks.

Hombre, pues si te planteas tener contenido comprimido que deba ser pasado a RAM, como gráficos, musicas o mapeado, puedes tenerlos en esa primera página del ROM de 48kb junto con una rutinilla de transferencia a RAM, de forma que, cuando necesites de su contenido, activas esa página y llamas a la rutina que hay en ella pasándole los destinos en registros, y después que regrese y tan anchos.

O sea, que de forma normal tienes que:

pag0.- BIOS (pag 0 del SLOT 0)
pag1.-16kb ROM (pag 1 del ROM (SLOT 1 o 2) )
pag2.-16kb ROM (pag 2 del ROM (SLOT 1 o 2) )
pag3.-16kb RAM (pag 3 del SLOT 3)

Cuando necesites de los buffers que tienes en la 1a pag del ROM cambias esa página para que:

pag0.-16kb ROM (pag 0 del ROM (SLOT 1 o 2) )
pag1.-16kb ROM (pag 1 del ROM (SLOT 1 o 2) )
pag2.-16kb ROM (pag 2 del ROM (SLOT 1 o 2) )
pag3.-16kb RAM (pag 3 del SLOT 3)

En esas primeras 16kb ROM metes una pequeña rutinilla de transferencia (con un simple ldir) para pasar datos a la RAM (siempre en la pag 3).
Una vez hecho, vuelves y activas la BIOS de nuevo a la página 0.

Así, el peso de la programación va en las páginas 1 y 2 del ROM, mientras que la página 0 la usas para contener datos puros y duros que los coges cuando quieras sin molestar al programa principal.

¿¿Me se ha entendidooo??  ::)  ;)

Understood, viejo_archivero. Me gusta la idea, así sólo se pierde tiempo con cambios de slots cuando hay que descomprimir datos tipo música, pantallas y tal. Que es, precisamente, cuando unos milisegundo arriba o abajo no se notan. Tomo nota! Gracias

The other option is to avoid the BIOS at all, usually this improves
a lot the performance of the VDP access and allows you to
optimize the code even further.

BIOS is your friend  ;)

No creas, ARTRAG, me lo había planteado. Pero, la verdad, después de ver que usando la BIOS me va lo suficientemente rápido (de hecho, la mayor parte del motor gráfico está listo y me sobra aún muuuucho Z80), he decidido seguir usando la BIOS. Si bien es cierto que usar 16KB para las cuatro rutinitas que realmente necesito es excesivo, pero no se puede pedir todo :)

Otra cosa sobre la memoria. Si uso la BIOS, no tengo más remedio que apechugar con la zona de trabajo del sistema en la parte alta de la RAM, no? O existe alguna forma sencilla de usarla? Si no es mucho preguntar, a partir de qué dirección no me conviene usar RAM?

Pues es una buena pregunta, yo no lo se exactamente... suelo contar con un tope imaginario de 12KB de uso en RAM, pero seguro que se puede usar un poco más... ¿alguien nos da el dato?  ;)

Creo que se puede usar exactamente .. a partir de lo que sería PILA .. no?
Y la zona de pila la obtienes en esta variable ...(#0xfc4a)

Si prescindes de la BIOS totalmente, es decir, desactivas la página 0 y reprogramas la ISR de $38 (o pasas a IM2); entonces estareis solos el Z80 y tú en un espacio de 64K, sin variables de sistema ni zarandajas.
La variable de entorno $FC4A no estoy seguro de que quede inicializada antes de que el programa salte a la dirección de arranque de la ROM, ante la duda lo mejor es ser un poco conservador y como supongo que no es plan de meterse en esos fregaos, lo mejor es redefinir el puntero de la pila no superando $F000. La rutina de arranque de la ROM te deja la pila un poco más arriba si no recuerdo mal (se puede comprobar fácil monitoreando el arranque de tu ROM con el BlueMSX), así que mejor no acercarse mucho.

Por lo que yo se .. si se inicializa .. de hecho yo la uso :)

Cierto, ya está inicializada a $F380. La pila del sistema andaba por la $F08E (en casi todos los MSX que he probado) pero supongo que la puedes machacar sin peligro, además tampoco es probable que crezca tanto tu pila.

... salvo que quieras utilizar programación recursiva en ensamblador: devorarás la pila, literalmente. Y si no me creéis, echadle un vistazo al código fuente del MINE SWEEPER.

Salvajes...¡si el Z80 tuviera puños os ibais a enterar! 2gf:)

Yo hago unas barbaridades reentrantes con mi función HOOK . .que la pila flipa que no veas .. veo los ojos del Z80 como me miran y me insultan :)

[nerlaska]  :P  :whip: [z80]

A ver que me aclare, porque estoy un poco espeso... Lo que me ha parecido entender es que la pila empieza en una dirección, llamemosle X, y crece hacia direcciones superiores a X. Por encima de ese X hay variables del sistema y demás, por lo que si la pila crece demasiado, las machaca y el invento se va a tomar por saco. ¿Correcto?

Por otro lado, he entendido que la pila marca el inicio de la zona de trabajo. Es decir, que la RAM con direcciones inferiores a X puedo usarla sin temor ¿Correcto?

Finalmente está el tema de modificar la dirección de inicio de la pila. Para modificarla ¿es suficiente con meter elvalor que quiera en el stack pointer al inicio de mi programa?

Gracias por la ayuda. La verdad es que, inocente de mi, había hecho mis cálculos suponiendo 16KB de RAM y, claro, ahora voy un poco justito. Me alegré ayer al comprobar que podía meter unas quince pantallas más o menos complejas en unos 800 bytes, pero aún así, entre replayer de PT3, músicas y buffers varios se me queda corta.

Jeje,.....no.....la pila crece hacia "abajo", es decir, hacia direcciones inferiores. Si defines SP como $F380, la primera posición ocupada de la pila será $F37E/$F37F, la siguiente $F37C/$F37D y así sucesivamente. Haciendo CLEAR ,&F380 impides que la pila de BASIC sobrepase esa dirección, eso te permite tener datos a partir de ahí y tener la garantía de que el intéprete no se los va a cargar, algo pareceido vendría a ser un LD SP,$F380.


Tampoco, tampoco :) . La pila puede estar situada donde se quiera dentro de lo que se considere zona de trabajo (usualmente la página 3); pero lo suficientemente separada de la zona de código y la zona de datos de tu programa como para que no los machaque. Por supuesto tampoco sería bueno ni definirla dentro del area de variables de sistema (si usas la BIOS) o en una página distinta a la 3 si vas a hacer conmutación de páginas.

Me apropio de un gráfico del MSX THB y lo corrijo un poco :


Ese sería el mapa visible desde el BASIC. Como desde un cartucho el interprete de BASIC desaparece y lo normal es que no activemos la unidad de disco tenemos (para una ROM de 16Kb):


Esa zona de RAM comprendida entre la dirección $C000 y $F380 estaría disponible para todo, variables, tablas, bufferes.....y la pila. Como crece hacia arriba (geométricamente hablando ;)), es necesario ubicarla lo más baja posible (sigo hablando geométricamente ::)) y calcular un margen de seguridad entre el final de tus datos y el tamaño teórico que alcanzará la misma, que será pequeño si no se hacen guarreridas españolas como las que hacen los señores Robsy y Nerlaska ;D


Nada más ni nada menos...


¿Y ya has probado a comprimir con el bitbuster o con el pletter?

Y el PLETTER ese .. comprime mucho más que el BitBuster? o no se aprecia demasiado? alguién sabe dar datos precisos?

PD: MSXScript is near!!! :D

Ese nerlaska, haciendo consultas de desarrollo MSXero a las 4.22 AM!!!!  :god: :god: :god:

A quien madruga .. Dios le ayuda ... :) .. llevo buenas sesiones de 4:00 AM .. desde que se me ocurrió meterme con lo de la DEV!!! señor!!
Pero que contento estoy!!!

¡Que moral!, no me extraña que a esas horas andes preguntando por esas rutinas, ¡¿no me digas que te estás empollando toda la BIOS?!

<Explicación a esas rutinas en el otro hilo>


Pues algo vi por ahí, era básicamente igual; pero habían proporcionado el código del compresor ;)

Gracias por la info, jltursan. Algo espeso si estaba, pero ya lo he pillado. Como no uso disco, he situado la pila en F380 y esos bytes que he ganado me vienen de perlas.

Sobre la compresión, estoy usando bitbuster y abusando de la RAM para ir descomprimiendo cosas. Mi ROM aún no llega a las 16KB, y mi idea es meter un montón de pantallas, enemigos y demás en 16KB más y tener una ROM de 32KB, con lo que el descompresor bitbuster acabará echando humo  :D

Pues para el que quiera probar el Pletter, aquí va la dirección :

Página de XL2S (http://www.xl2s.tk/)

Lo podeis encontrar en la sección de Tools.

Hmmm... le he echado una ojeadilla rápida al pletter... son imaginaciones mías o el descompresor de pletter es mucho más corto que el de bitbuster??