Karoshi MSX Community

A ver...

Tengo un juego de patrones en un SR5 (que ya cumple las restricciones del SR2 y blablabla). Hay alguna utilidad con la que pueda convertir ese juego de patrones a DATA's en basic??

Graaaaaacias paaaaayos!

Pues puedes hacer un programita en BASIC que lo haga. Básicamente sería:

Cargas la pantalla en SC5.
Cada patrón está formado por un bloque de 8x8, así que primero tenemos que hacer una rutina para convertir un byte. Si (X,Y) son las coordenadas de inicio del byte a convertir...


Ahora tienes en B el byte para la tabla de patrones y en C el byte para la tabla de colores. Si repites esto con todos los bytes ya puedes convertir tu pantalla SC5 en SC2. Lo mejor sería pokear en RAM y luego guardarlo todo con un BSAVE, más eficiente que los DATA, aunque también puedes generar un fichero de texto con los DATA.

Tú decides.

Saludos
--
SapphiRe

Ya, ya... me refería a si ya existía algo que lo hiciese... para evitarme hacerlo yo mismo...


Pero si quiero hacer una rom, lo suyo serían los data's, no?...

Al contrario, los datos en RAM serían mejor, siempre se pueden meter a capón en la ROM y ocupan mucho menos que los DATA's...

¡Esasto!, te ahorras la valiosa memoria que ocupan las lineas con DATA. Si esos datos los vas a integrar en una ROM BASIC puedes utilizar <publicidad una vez más>este programita (http://www.telefonica.net/web2/msxpage/ROMcreator.exe)</publicidad una vez más> con el que podrás crear el binario de la ROM (de 16Kb) a partir de un listado TOKENIZADO de BASIC y el binario con los datos de gráficos, rutinas de CM, música, etc.

Pero admite varios binarios o ha de ser un binario con todo?

Bueno la idea es que sea solo 1 binario, ¿por qué?; pues porque en este tipo de ROMs sueles andar muy pillado de sitio y no tiene sentido el tener varios ficheros con huecos por enmedio. También es cierto que el programa podría pedir varios binarios y el sólo irlos colocando consecutivamente en memoria; pero en su momento y como a mi me gusta tenerlo todo muy controlado, preferí ser yo el que los juntara y planificara en un solo archivo :P
Para los que usan Windows, siempre se puede hacer COPY /B FILE1+FILE2 FILE3 y así se juntas todos los trozos en uno.

Más preguntillas sobre el Romcreator...

Imaginemos que tengo un programa en basic que hace un bload de un BIN que te carga los tres sets de patrones en VRAM. Al usar el Romcreator me vale ese mismo BIN o ha de retocarse de alguna forma?

Funciona perfectamente. La ROM de 16K que se crea, contiene todos los datos binarios que tú desde el programa cargarías normalmente con BLOAD. SI te fijas, en el programa hay un mapa de memoría de la página 2 en el que puedes ver gráficamente como quedan los bloques de BASIC y los binarios.

Y cómo hago que se ejecute el binario??... o sea si antes, teniendo todo en un mismo directorio, ejecutaba el binario desde el programa basic con un bload, cómo hago que se ejecute ahora que está 'incrustado' en la rom??  ???

Perdona mi pardillismo...

Cuando haces un BLOAD"xxxx",R, lo que haces son dos cosas: cargar el binario en memoria (que en la ROM a todos los efectos es como si ya lo hubieras cargado, te ahorras el BLOAD) y ejecutar algo en CM que tengas en ese binario, esto último lo puedes hacer con un DEFUSR=&Hxxxx, siendo xxxx la dirección en la que comenzará esa rutina.
Vamos, que la principal diferencia entre el BASIC de ambas versiones de tu programa es que antes tendrías un BLOAD"xxx",R y ahora no tendrás que usar BLOAD, sino únicamente un DEFUSR con su correspondiente USR. En ese binario, como es lógico, puedes tener de todo, más rutinas CM para definir con otros DEFUSR, datos gráficos que podrás usar directamente desde el BASIC, etc.
Lo único que tienes que tener claro es donde acaba tu programa BASIC y donde situas ese binario, que deberá estar comprendido entre ese final del BASIC y la última dirección de la página 2 ($BFFF)
En cuanto hagas alguna pruebecilla lo veras claro, clarete... ;)

my 'lazy' method would be (getting back to the start of the thread): (sorry this message being in english)
- running your stuff on an emulator, take a screenshot displaying all patterns you may have, or even from original pictures (png, bmp, tiff...) you may have too
- edit the resultant picture you have in a 256 character pattern screen - 256x64 pixels (a bit like the pp file resulting from the fmsx-dos screenshot), or use a converter  (like that ones from me, Robsy, etc... )
- the result maybe should be binary - use a hex editor (like Hex Workshop) or some code script (me and Robsy as well may have somewhere a bin to .asm or bin to hexdump converter) - converting later to msx-basic is not that difficult

i think that's all...

Ok, ya capto.


Esa es otra... de cuánta 'zona libre segura' de memoria se dispone como mínimo??... es decir, dónde acaba la memoria disponible del basic como máximo y hasta donde me queda libre (en el peor de los casos)??... es para no ir tocando la dirección de inicio del binario a medida que va creciendo el programa basic.


Eso espero... :-\

No me había dado cuenta de que mi último post había salido como el culo... lo acabo de editar.

Para ver hasta donde se extiende tu BASIC, puedes cargar el archivo .BAS (tokenizado) en el ROMCreator y te indicará el rango de memoria que ocupa, el binario podrá ocupar la zona comprendida entre la dirección de fin del BASIC y la direccion $BFFF, ni un byte más, ni un byte menos. :(
Aunque eso no es del todo cierto, claro. Si en el binario tienes datos comprimidos, los puedes descomprimir libremente en la página 3 ($C000) que siempre es RAM; así podrás aprovechar aún más el poco espacio libre que te deje el BASIC ;)

Cierto. El programa de José Luis es magnífico aunque no pienses incluso incluir complejas rutinas en c.m. Con tan sólo volcar el juego de caracteres (que de todas formas, si quieres cambiar el que viene por defecto, tendrías que meter montones de datas) ya vale la pena a cualquiera que programe en basic, pues con un simple cargador (una llamada a la BIOS) y los datos, te ahorras más espacio que tener que meterlo en datas y además es casi instantáneo (nada de "POR FAVOR, ESPERE...").

Ya, eso ya lo he visto. Me refería a, sin saber previamente cuánto me va a ocupar el programa basic, donde puedo ubicar el BIN para que no entren en conflicto, ocupe lo que ocupe el programa basic.


Y no se puede ubicar el bin directamente en $C000, entonces??


Para eso es precisamente para lo que lo quiero usar (bueno, y según como vaya la cosa con el tema del sonido, puede que también para posibles músicas).

Siempre habrá peligro de colisión ya que ambos tendrán que entrar en la página 2, el truco del almendruco es que ya que el BASIC va pegado al extremo superior, &H8000; puedes alejar lo máximo posible el binario pegándolo a &HBFFF. El problema es que tendrás que vigilar que a medida que tu BASIC crezca no acabe pisando el binario, en cuanto eso pase, se acabó, o reduces tamaño o comprimes datos :P.


Directamente no (que yo sepa), una ROM BASIC oficial únicamente ocupa la página 2 ($8000-$BFFF), todo lo que quieras meter tiene que ir apretado ahí. Eres libre después de mover cosas a $C000; pero ya una vez que el programa ha arrancado, claro. Hay que aprovechar hasta el último byte de la página... cmptr:)

Tienes que tener siempre en cuenta lo que ocupa el basic, ya que la rom va a ocupar 16kbs (la página 2 completa), por tanto esos 16kbs serán basic+c.m. en cualquier caso. Si quieres sentirte seguro al meter el basic, haz un clear y reserva memoria y ya está. ¿Quieres dejar 8kbs para el basic y así asegurarte 8kbs para el c.m.? Pues haces un clear 200,32768+8192 y en cuantito te pongas a meter el programa basic y te pases de la raya, te saldrá un "out of memory". Esto es a lo bestia, pero es para que te vayas guiando, ya que NO puedes ocupar los 16kbs con basic solamente.



No por lo comentado arriba. La rom te va a ocupar desde la 32768 hasta la 49152, o sea que nada de usar de $c000 en adelante. Por eso lo del clear, tienes que reservarte y asegurarte espacio para poder meter las datas.



Pues con un poco más de 2kbs tienes para meter todo el juego de caracteres :) Con el asmsx y un editor de textos te creas un archivo tipo:

Pero cuidadín, que si es un programa BASIC que se está ejecutando en ROM, no puedes hacer una reserva de memoria sobre la propia página dos, tendría que hacerse el clear a partir de la dirección $C000, que ya es RAM de la buena  ;)
La verdad es que no lo he probado; pero supongo que pasarán cosas raras... ::)

Uarrrgg, se ha comido un trozo del texto  >:(

Bueno, Imanok, como te decía, con esto te haces de paso un screen1, con sprites ampliados, key off, colores, y además te vuelca el set de caracteres en un momento. Si quieres te lo modifico para screen2.

Y si necesitas aún así más memoria, siempre queda el método usado en la rom del Manicomio: rom en página 1,compresión, rutinas en asm, descompresión, cambio de página para conectar el intérprete y a rular. Esto dicho así no lo entiende ni el Nishi, pero te paso una plantilla con la estructura de la rom donde sólo tendrías que rellenar lo que falta y listo.  ;D

¡Cierto!  :D Me refería a que mientras introduzca Imanok el listado basic en el intérprete, se haga un clear para que le avise en cuanto pase de cierta cantidad de memoria, más que nada para controlar cuánto le falta, etc. Es verdad que una vez hecho rom, el clear lo jode bastante todo, algo así ya me pasó en el Manicomio.

Ok, comprendido  :)

Que si no se usa compresión para volcar luego a la página 3, hay que hacerlo a ojo de buen cubero, vamos... y para evitar sustos en la medida de lo posible, poner el BIN lo mas arriba posible en la página 2.

Ahora me toca experimentar y experimentar!... ya os comentaré si me atranco...


No será necesario (al menos por ahora, que aún no he empezado a teclear)... muchas gracias majos!!  ;)

Pues que rule esa plantilla ;D. A lo mejor puede convertirse en un modelo para que lo incluya en el ROMCreator.

Una cosita más sobre el ROMcreator... cuando añade el bin a la rom, le quita la cabecera del BLOAD??

Sip. El resultado final es un archivo ROM con la típica cabecera "AB" que no es cargable mediante BLOAD, LOAD ó demás comandos del BASIC.

No sé si hablamos de lo mismo, pero por si acaso...

Me refiero a que si le quitas la cabecera BLOAD al bin que añades dentro de la rom.

Claro, con lo de que la salida es un binario de tipo ROM me refiero a que cualquier otra cabecera ya no tiene uso, ni la cabecera del BASIC que has incluido (que usualmente cargarías con (C)LOAD) o la del binario (cargable con BLOAD).
Realmente esta ROM no es más que un volcado más o menos directo de la memoria entre $8000 y $BFFF; por eso, al incluir el binario dentro de este rango pierde su identidad y se hace uno con el todo...(joer, parezco un jedi... nnchks:))

Okey Mackey!  ;)

Bueno, Ockey Mackey... o no...

Releyendo otra vez, aún me quedan dudas... porque una cosa es que no se use y otra cosa es que no la incluyas... a ver si ésta es ya la refinitiva, que me estoy haciendo cansino....  :-\

Cuando el ROMcreator "pega" el binario junto con el BASIC ... ¿pega TODO el binario (incluídos los 7 bytes de cabecera) o pega solo la parte "usable" y en el sitio donde indica esa cabecera?

Es que claro, si mi programa CM se ejecuta en 0B000h y está en un BIN cargable con BLOAD, y el ROMcreator lo pega todo, tendría que pegarlo en 0B000h -7, para que al hacer el DEFUSR se ejecute donde toque ...

Cansino, que soy un cansino!!  :P

Tu mismo lo acabas de decir, de un binario sólo se aprovecha la parte "usable", la cabecera sólo sirve para saber en que parte de la memoria se carga. Pues aquí igual, si tú tienes un binario que empieza en &HB000; pues ahí se te va a quedar :).
Igualmente, los DEFUSR que tuvieras preparados no cambian de posición.

Ok  ;)

Otra cosa, a modo de comentario sobre el ROMcreator... creo que mostrar la dirección &HC000 como dirección final lía, ya que
la dirección final sería &HBFFF, no??

Me ha pasado al querer incluir el bin en cuestión lo más arriba posible en memoria, ya que me daba como dirección final &HC000 y no sabía si es que me había pasado un byte o es que daba esa dirección final erroneamente...

Pues la verdad es que sí   :-[


Y ahí vuelves a tener razón, en la práctica tengo un fallo ya que al origen le sumo el tamaño y eso da una dirección final un byte por encima de la que realmente debería ser :P. Si te daba &HC000 eso significa que el último byte debía estar en &HBFFF, tu apreciación era correcta :)
¡Buf!, de momento y aunque tengo la versión 2 a medias, no tengo pensado retomar el tema; pero la verdad es que ya tengo un montón de sugerencias y correciones acumuladas  cmptr:)