Karoshi MSX Community
05 de Julio de 2021, 07:21:18 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: [1] 2
  Imprimir  
Autor Tema: Consulta sobre la C-Bios  (Leído 7850 veces)
0 Usuarios y 1 Visitante están viendo este tema.
Jos'b
Karoshi Maniac
****
Mensajes: 262


« : 17 de Septiembre de 2011, 09:33:54 am »

Lo que me interesa saber es que tiene de especial o de diferente la C-Bios del resto de Bios.

Como ya sabeis, estoy intentando hacer un programilla de ajedrez para la DEV de este año, y me he encontrado con la curiosa situación de que funciona perfectamente en todos los emuladores (y MSX's reales), salvo los que usan (o cuando se usa) la C-Bios.

El problema tiene que ver con los sprites y es sencillamente que no coloca el sprite según las coordenadas que le introduzco. Es curioso, porque como he dicho, funciona en todos los emuladores o MSXs (bueno en todos no se) pero no funciona cuando se usa la C-bios, coloca el sprite donde le parece (aunque siempre en el mismo sitio)

En realidad es un problema al que no le he dado mucha importancia, porque en el fondo lo que me interesa es que funcione en un ordenador real. Pero como es muy posible que quien lo pruebe lo hara casí al 100% de seguridad sobre algún emulador, antes de que me lluevan las críticas, intentaré resolver el problema para que funcione bien en cualquier plataforma.

Si alguien tiene alguna sugerencia, aquí estoy para recibirla   Smiley

En línea
pitpan
Karoshi Forum's Guru
*******
Mensajes: 1812


« Respuesta #1 : 17 de Septiembre de 2011, 10:29:34 am »

Pues sí, C-BIOS tiene algún bug. Por ejemplo, el G-MONKEY que programé para el mini-concurso open-source que se hizo por aquí, no funcionaba bien con C-BIOS porque no estaba bien implementada la función de leer el color de un pixel en SCREEN 2.

Cuéntanos qué rutina en concreto te está fallando y cuando le pasas qué parámetros, y trataremos de encontrar una solución alternativa que sea compatible con la BIOS "oficial" y C-BIOS.
En línea
SapphiRe_MSX
Visitante
« Respuesta #2 : 17 de Septiembre de 2011, 11:40:38 am »

Yo también me he encontrado con diversas incompatibilidades de la C-BIOS, por lo que al final pasé casi completamente de la BIOS y sólo la utilizo para la inicialización. Si comentas qué se supone que hace la rutina que te interesa siempre podemos intentar hacerla sin usar la BIOS y así no tendrías incompatibilidades.
En línea
Jos'b
Karoshi Maniac
****
Mensajes: 262


« Respuesta #3 : 17 de Septiembre de 2011, 12:06:14 pm »

Os pongo la rutina que da problemas, (solo en la actualización de las coordenadas de sprite)
Código:
void put_sprite(char plane, char x, char y, char clor, char sp)

{

/*

    register inputs:

        - a = Plano

        - b = Coordenada en X del sprite

        - c = Coordenada en Y del Sprite

        - d = Número de sprite a imprimir

        - e = Color del sprite



*/

    plane=plane;

    x=x;

    y=y;

    clor=clor;

    sp=sp;



    _asm



    ld a,4(ix)

    ld b,5(ix)

    ld c,6(ix)

    ld e,7(ix)

    ld d,8(ix)



   

    push bc                ; Reserva registro BC para poder usarlo en otras cosas



    ld c,a                ; C=A                   

    add a,c                ; Al contenido de A se le añaden 3 veces más de A, que es

    add a,c                ; lo mismo que A=A+A+A+A, con esto se calcula el OFFSET

    add a,c                ; del plano dentro de la tabla de atributos de sprites



    ld b,#0x0000            ; B=0

    ld c,a                ; C=A equivale a LD BC,A



    ld iy,#0x1B00            ; Apunta a la tabla de atributos de sprites

    add iy,bc            ; Desplaza posición VRAM hasta el plano elegido en A

    push iy                ; Empuja IY para pasar valor a HL, es igual a LD IX,BC

    pop hl                ; HL contiene la posición VRAM en la tabla de atributos



    xor a                ; A=0

    add a,d                ; Al contenido de A se le añaden 4 veces más de D, que es

    add a,d                ; lo mismo que A=4*D. Con esto se consigue acceder al 

    add a,d                ; sprite numero D definido en tabla de patrones sprites

    add a,d                ; Para el caso de sprites de 8x8 sobrarían estas líneas

    ld d,a                ; Se actualiza el valor correcto para D en sprites de 16



    pop bc                ; Recupera valores de posición X e Y del sprite



    ld a,c                ; Posiciona sprite en Y

    call 0x004D            ; VPOKE HL,C

    inc hl                ; Siguiente posición de la tabla de atributos

    ld a,b                ; Posiciona sprite en X

    call 0x004D            ; VPOKE HL,B

    inc hl                ; Siguiente posición de la tabla de atributos

    ld a,d                ; Número de sprite a imprimir

    call 0x004D            ; VPOKE HL,D

    inc hl                ; Siguiente posición de la tabla de atributos

    ld a,e                ; Color del sprite       

    call 0x004D            ; VPOKE HL,E

   

    _endasm;   

}


aunque creo que no tiene nada que ver con ella, pq curiosamente he estado haciendo los siguientes cambios en el código esta mañana

Código:
void main (void)

{
    unsigned char k,select;

    unsigned char x,y;          /* coordenadas reales del puntero en pantalla */

    unsigned char xx,yy;        /* coordenadas reales del puntero que queda fijo despues de elegir pieza */

     unsigned char xb,yb;           /* escaque asociado al puntero (x,y) (se debe actualizar a la vez) */



    unsigned long int i;

    /* Inicializa pila */

    _asm

        di

        ld sp, (#0xFC4A)

        ei

    _endasm;


    g_slotPort = (g_slotPort & 0xCF) | ((g_slotPort & 0x0C) << 2);   

    ..... resto del código

por lo siguiente

Código:
void main (void)

{
       /* Inicializa pila */

    _asm

        di

        ld sp, (#0xFC4A)

        ei

    _endasm;


    g_slotPort = (g_slotPort & 0xCF) | ((g_slotPort & 0x0C) << 2);   

    lanza_programa_de juego();
}

void lanza_programa_de_juego(void)
{
    .... código
}

y la rutina del sprite funciona perfectamente, sin embargo, todo lo demás se va al carajo (perdón por la expresión), todo lo demás me refiero a que salen errores en cualquier sitio y solo ocurre con la C-bios  Huh


también despues de modificar el código de la siguiente forma

Código:
void main (void)

{
      /* Inicializa pila */

    _asm

        di

        ld sp, (#0xFC4A)

        ei

    _endasm;


   g_slotPort = (g_slotPort & 0xCF) | ((g_slotPort & 0x0C) << 2;

   unsigned char k,select;

    unsigned char x,y;          /* coordenadas reales del puntero en pantalla */

    unsigned char xx,yy;        /* coordenadas reales del puntero que queda fijo despues de elegir pieza */

    unsigned char xb,yb;           /* escaque asociado al puntero (x,y) (se debe actualizar a la vez) */

    ... etc
}

el compilador SDCC me da error en el primer unsigned (de la declaración de variables)


así que realmente no tengo ni idea de donde puede estar el error, ¿el compilador? ¿la C-Bios? ¿o yo que no tengo ni idea de C y me meto en estos berenjenales?
En línea
pitpan
Karoshi Forum's Guru
*******
Mensajes: 1812


« Respuesta #4 : 17 de Septiembre de 2011, 01:23:37 pm »

Buf. Si estás mezclando C y ensamblador no sé si podré ayudarte... En cualquier caso, podría suceder que la rutina que estás utilizando 0x004D, que supongo que es WRTVRM, en la versión BIOS "oficial" sólo modifica EI. Pero es posible que en la versión de C-BIOS (habría que verificar el código fuente) te sobreescriba algún registro. Prueba a hacer PUSH de todos los registros, incluidos IX e IY, antes de cada CALL 0x004D, y después los correspondientes POP, a ver si así funciona.

De todos modos, el código me parece algo denso como para ponerme a depurarlo así tal cual. Por cierto, ten en cuenta que la instrucciones que emplean registros de índice son más lentas y consumen bastante más memoria que las que no los usan.
En línea
phsoft
Karoshi Fan
**
Mensajes: 68



WWW
« Respuesta #5 : 17 de Septiembre de 2011, 05:07:39 pm »

Citar
la rutina que estás utilizando 0x004D, que supongo que es WRTVRM, en la versión BIOS "oficial"

buenas,
creo que esto que copia debajo es la rutina 0x4d desensamblada de la bios de un msx1, el panasonic cf-2700 (mi primer msx). antaño yo es perdía el tiempo con estas cosas.. coñe, como ahora! Joe

Código:
VPOKE:
push af
ld a, l
di
out [0x99], a
ld a, h
and 0x3f
or 0x40
out [0x99], a
ex [sp], hl
ex [sp], hl
pop af
out [0x98], a
ret

usa el debugger de bluemsx, por ejemplo, y lo compruebas. ojo que va sin probar. la pongo por si quieres probarla, insertándola en tu código.. de todas formas yo es que solo usaría la c-bios como curiosidad, o para pruebas, o para extraer/ver/estudiar alguna rutina. esa bios es una iniciativa muy interesante y sería fantástico que estuviera acabada, con código en abierto y fuese totalmente compatible. por soñar Shocked pero vamos, ahora que pitpan no me oye angel, a mi con un desensamblado de las rutinas bios más importantes (que son las de inicialización, pienso) ya me valdría... y por cierto que recuerdo código para el msxpad que, parecido al tuyo, mezclaba pascal con asm y contenía rutinas interesantes para el manejo del vdp, el sonido, etc. era de algún programador o grupo holandés, si recuerdo bien...

saludos,
- paco
En línea
Jos'b
Karoshi Maniac
****
Mensajes: 262


« Respuesta #6 : 17 de Septiembre de 2011, 06:50:36 pm »

Buf. Si estás mezclando C y ensamblador no sé si podré ayudarte...
Eso pensé yo cuando valoré la posibilidad de hacer un juego de este tipo en ensamblador... buf  Cheesy

sinceramente, no se si sería capaz de implementar toda la lógica que requiere el juego en ASM puro y duro. Y si fuera capaz, seguramente me llevaría siglos

creo que esto que copia debajo es la rutina 0x4d desensamblada de la bios de un msx1, el panasonic cf-2700 (mi primer msx). antaño yo es perdía el tiempo con estas cosas.. coñe, como ahora! Joe

con los cambios que propones (vamos sin usar la bios, al fin y al cabo) da el mismo error  Angry


quiero dejar claro, de nuevo, que solo hay problemas con la C-Bios, con el resto de ROMs funcionan perfectamente, por eso se me hace un poco raro que incluso no usando los servicios de la bios cometa esos errores.


de cualquier modo, siempre está la opción de incluir la "no compatibilidad con C-Bios", pero antes de darme por vencido quiero intentar resolver el asunto.
En línea
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #7 : 17 de Septiembre de 2011, 09:09:33 pm »

Hola Jos'B

yo utilizo lo siguiente y me funciona con el C-Bios

el putsprite esta adaptado para el uso de sprites de 16x16. Para 8x8 habría que quitarle el "*4" del calculo de la dirección de memoria de los atributos de sprites (variable "vmem")

Te adjunto también los fuentes de una librería con funciones para trabajar con el VDP de los MSX1 con BIOS.

Saludos!

Código:
void vpoke(unsigned int address, unsigned char value)
{
  address;
  value;
__asm
  ld l,4(ix)
  ld h,5(ix)
  ld a,6(ix)
  call 0x004D
__endasm;
}


/* ===========================================================================
 put_sprite
 Function :
    Muestra un sprite en la pantalla.
    Displays a sprite on the screen. 
 Input    : number - numero de plano                     
            xpos - coordenada x
            ypos - coordenada y
            color - color
 by Andrear           
=========================================================================== */
/*
void put_sprite(byte number, byte xpos, byte ypos, byte color)
{
  unsigned int vmem=0x1B00+(number&0xff)*4;
  vpoke(vmem+0,ypos);
  vpoke(vmem+1,xpos);
  vpoke(vmem+3,color);
}
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #8 : 17 de Septiembre de 2011, 09:14:50 pm »

Me olvidaba.

Algunas de las funciones no son mías, pero solicité el permiso a los correspondientes autores (Andrear y L!T), por lo que se pueden usar sin problemas.

Saludos!

En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
samsaga2
Karoshi Fan
**
Mensajes: 76


Email
« Respuesta #9 : 18 de Septiembre de 2011, 07:35:30 am »

No es muy eficiente llamar una rutina para pintar los sprites uno por uno. Es mejor tener un array con la misma estructura que la vram e ir volcándola entera con outir.

De todas formas he mirado la rutina de la cbios y no parece que se cargue ningún registro que no deba.

cbios.svn.sourceforge.net/viewvc/cbios/cbios/trunk/src/video.asm?revision=590&view=markup

Yo no me preocuparía demasiado mientras funcione en un msx real. En la misma web de la cbios hay una lista de juegos incompatibles. 
En línea
Jos'b
Karoshi Maniac
****
Mensajes: 262


« Respuesta #10 : 18 de Septiembre de 2011, 11:01:10 am »

Hola aorante
=> gracias por la subida, curiosamente yo tambien tengo un archivo similar de cuando andrear presentó su juego a la DEV de algún año que ahora no recuerdo y liberó el código. En relación al código del VPOKE, es igual al que tengo, de hecho con SDCC no sé si se puede hacer de otra manera.

Lo que si modifique ayer es la función de putsprite añadiendo vpokes y quitando el código ASM. No se pq lo tenía así, seguramente son de esas cosas que una vez hechas y funcionan, caen en el olvido hasta que aparecen problemas y esas cosas.

De todas formas, no tengo muy claro que el problema sea de las llamadas a la C-Bios, tiene que haber algo que se me está pasando y no doy con ello. El problema real es que cuando modifico las variables x e y que corresponden al cursor (el sprite que selecciona y hace mover las piezas) que funciona en todas las roms incluida la C-bios, al invertir el tablero por ejemplo, hago una simple operación del tipo x=200-x e y=200-y, y el resultado es que en todas las BIOS funciona la simetría en las coordenadas, pero con la C-bios no, las coordenadas se colocan más o menos donde le parece, y eso da como resultado que el cursor del juego ya no se comporte bien. No se si he conseguido explicarme.

La conclusión a que he llegado es que hay algún conflicto entre el código y la C-Bios (solo la c-bios) al iniciar la pila o algo así que afecta a la zona donde se alojan las variables y que solo afecta a la C-bios.

Tambien he detectado algunas cosas curiosas con SDCC, a veces da la sensación de que variables que ha sido declaradas en un ámbito local son modificadas por partes de código que estan en otro sitio. Es como si el compilador asignara dos posiciones de memoria identicas para dos variables diferentes. Esto, obviamente, es una suposición mía. Además tampoco explicaría que el juego se comportase bien con las ROM oficiales y mal con la C-Bios.

En fin, seguiré mirando el código a ver si doy con el posible fallo.

@samsaga2: Llevas razón, la rutina del sprite se puede mejorar Smiley, aunque en realidad solo se usa un sprite, no hace falta mas. Y en realidad tampoco estaba muy preocupado sobre el asunto, pero a parte de que me parecía curiosa la situación, ¿por qué no intentar resolverla?
« Última modificación: 18 de Septiembre de 2011, 11:17:42 am por Jos'b » En línea
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #11 : 18 de Septiembre de 2011, 03:13:34 pm »

Hola aorante
=> gracias por la subida, curiosamente yo tambien tengo un archivo similar de cuando andrear presentó su juego a la DEV de algún año que ahora no recuerdo y liberó el código. En relación al código del VPOKE, es igual al que tengo, de hecho con SDCC no sé si se puede hacer de otra manera.

y tanto que se puede!  Wink

Esta seria la forma de hacerlo sin BIOS, suponiendo que los puertos son los 98 y 99.

Código:
void vpoke(uint address, byte value)
{
  address;
  value;
__asm
  di
  ld l,4(ix)
  ld h,5(ix)
   
  di
  ld a,l
  out (0x99),a
  ld a,h       
  add a,#0x40
  out (0x99),a
  ei
  ld a,6(ix)
  out (0x98),a
  ei
__endasm; 
}
Nota: Estoy preparando una lib equivalente a la que te pase pero sin uso de la bios, para aplicaciones MSX-DOS
y tengo otra para tocar los registros del PSG. Cuando las tenga listas las publicaré.

Según como sea el juego o la app, se puede hacer un buffer en la RAM y en la interrupción volcarlo a la VRAM con una rutina en Asm rápida. Para sprites y tiles creo que se puede utilizar un outi o un outir sin problema del cuello de botella del acceso a VRAM del VDP de los MSX1. En estos foros puedes encontrara más info detallada de este tema.

Otra forma es la que me enseño marq de L!T, más limpia y seguramente más optima que la anterior:
(http://www.kameli.net/lt/index.html). Trabajan en SDCC y suelen poner los fuentes de algunas de sus producciones.

Código:
//definir al principio del codigo
__sfr __at 0x98 vdp1;
__sfr __at 0x99 vdp2;

// funcion
void vpoke(uint address, byte value)
{
  vdp2=address;
  vdp2=(address>>8)|0x40;
  vdp1=value;
}

Lo que si modifique ayer es la función de putsprite añadiendo vpokes y quitando el código ASM. No se pq lo tenía así, seguramente son de esas cosas que una vez hechas y funcionan, caen en el olvido hasta que aparecen problemas y esas cosas.

De todas formas, no tengo muy claro que el problema sea de las llamadas a la C-Bios, tiene que haber algo que se me está pasando y no doy con ello. El problema real es que cuando modifico las variables x e y que corresponden al cursor (el sprite que selecciona y hace mover las piezas) que funciona en todas las roms incluida la C-bios, al invertir el tablero por ejemplo, hago una simple operación del tipo x=200-x e y=200-y, y el resultado es que en todas las BIOS funciona la simetría en las coordenadas, pero con la C-bios no, las coordenadas se colocan más o menos donde le parece, y eso da como resultado que el cursor del juego ya no se comporte bien. No se si he conseguido explicarme.

Si pinchas a la BIOS por direcciones no "oficiales" es muy probable que alguna cosa no funcione. Lo digo por que vi recientemente una lista de accesos, en estos foros (no recuerdo de quien), que pinchaba directamente a partes de la BIOS, para usar funciones del BASIC. Es probable que no se correspondan con la C-BIOS.

Las funciones de la BIOS están descritas aquí:
http://map.grauw.nl/resources/msxbios.php#msx1bios

La conclusión a que he llegado es que hay algún conflicto entre el código y la C-Bios (solo la c-bios) al iniciar la pila o algo así que afecta a la zona donde se alojan las variables y que solo afecta a la C-bios.

Tambien he detectado algunas cosas curiosas con SDCC, a veces da la sensación de que variables que ha sido declaradas en un ámbito local son modificadas por partes de código que estan en otro sitio. Es como si el compilador asignara dos posiciones de memoria identicas para dos variables diferentes. Esto, obviamente, es una suposición mía. Además tampoco explicaría que el juego se comportase bien con las ROM oficiales y mal con la C-Bios.

En fin, seguiré mirando el código a ver si doy con el posible fallo.

Yo no he tenido ese problema, pero para controlar donde tienes todos los datos hay que ser muy metodico y organizado. Yo soy de los anárquicos que les cuesta poner comentarios  Griel

Cuando usas punteros la cosa se lía más...

Justamente ayer puse en el blog del proyecto PSGed un post sobre un tema relacionado con el SDCC. Hay más notas sobre programación con SDCC y quiero ir añadiendo todas aquellas cosas que he aprendido a base de palos  Cheesy
http://psged.blogspot.com/search/label/programaci%C3%B3n

Saludos!
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Jos'b
Karoshi Maniac
****
Mensajes: 262


« Respuesta #12 : 18 de Septiembre de 2011, 08:39:30 pm »

Bueno en realidad me refería a una funcion en SDCC usando la BIOS, sin la BIOS, en este mismo hilo hay una versión posteada por phsoft, que 'curiosamente' funciona con todas las roms, pero con la C-Bios da error, por eso me da que pensar que no tiene nada que ver con las llamadas a la BIOS sino algún otro conflicto.  De hay mi primer post, cuando preguntaba si la C-Bios tiene algo de especial al resto. En realidad debería haber preguntado en que difiere al arrancar del resto de las roms, quizás esto me dé alguna pista del posible error.

Citar
Otra forma es la que me enseño marq de L!T, más limpia y seguramente más optima que la anterior:
(http://www.kameli.net/lt/index.html). Trabajan en SDCC y suelen poner los fuentes de algunas de sus producciones.

Código:

//definir al principio del codigo
__sfr __at 0x98 vdp1;
__sfr __at 0x99 vdp2;

// funcion
void vpoke(uint address, byte value)
{
  vdp2=address;
  vdp2=(address>>Cool|0x40;
  vdp1=value;
}
esto me lo apunto Cheesy (aunque hay por aquí alguien que no es partidario de dar por supuesto que los puertos 98 y 99 coinciden en todos los MSXs)

Citar
Yo no he tenido ese problema, pero para controlar donde tienes todos los datos hay que ser muy metodico y organizado. Yo soy de los anárquicos que les cuesta poner comentarios  Griel

Cuando usas punteros la cosa se lía más...
Pues yo intento ser bastante organizado, aunque siempre me surgen problemas en los lugares más insospechados  Smiley, y al final siempre me consuelo pensando que solo soy un aficionado a la programación Magical Stones

En fin, no se que hacer con la C-Bios, creo que voy a pasar y ya está, entre otras cosas pq tengo que resolver algún que otro problema todavía y que me ha llevado todo el día (el deadline me esta empezando a poner un poco nervioso Cheesy)

[offtopic]
tengo que añadir tu blog a mis favoritos, he encontrado alguna cosa que creo que me será util en el futuro  Smiley
[/offtopic]
« Última modificación: 18 de Septiembre de 2011, 09:03:21 pm por Jos'b » En línea
samsaga2
Karoshi Fan
**
Mensajes: 76


Email
« Respuesta #13 : 19 de Septiembre de 2011, 07:56:32 am »

En fin, no se que hacer con la C-Bios, creo que voy a pasar y ya está, entre otras cosas pq tengo que resolver algún que otro problema todavía y que me ha llevado todo el día (el deadline me esta empezando a poner un poco nervioso Cheesy)

Si tanto te preocupa lo mejor que puedes hacer es tirar del bluemsx. Le pones las roms de cbios, generas los archivos sym con el compilador sdcc, cargas la rom, el archivo sym en el debugger y pones un breakpoint donde crees que falla. Así lo verás mucho más claro.

De todas formas si te funciona en un msx real, el problema con la cbios es un problema menor.
En línea
phsoft
Karoshi Fan
**
Mensajes: 68



WWW
« Respuesta #14 : 19 de Septiembre de 2011, 03:32:31 pm »

buenas, neng

Citar
por eso me da que pensar que no tiene nada que ver con las llamadas a la BIOS sino algún otro conflicto. De hay mi primer post, cuando preguntaba si la C-Bios tiene algo de especial al resto.


bueno, hay cosas que ella misma te dice, pej, si tratas de arrancarla sin una rom: No cartridge found. This version of C-BIOS can only start frigorífiques. Please restart your MSX (emulator) with a cartridge inserted. Grin de lo que se deriva, pienso, la perogrullá de que c-bios no es un clon de la bios de un msx (1, 2, 2+.. lo cualo?) al completo, solo es una pequeña parte de aquellas bios. entonces c-bios intenta ser compatible solo con aquella parte que inicializa la máquina y arranca un cartucho. chimp púm. también te dice que está diseñada para correr sobre emuladores (auque no solo software, quizá), en ningún caso sobre msx reales.. que todavía existen! X..-D esto son perogrulladas o no, depende de lo que el diseñador de aquella bios, digo yo, pensara que era absolutamente imprescindible para arrancar un cartucho según la norma msx (reinterpretada por él, supongo), lo qué podía ser prescindible, lo que no hacía falta pero se podía poner, etc. un msx.. tu acuérdate Grin arranca todo un señorito bisic esto cuando no tira de disquetera y todo.. y eso es arrancar una tacada de cosas innecesarias para el correr del cartucho

Citar
En realidad debería haber preguntado en que difiere al arrancar del resto de las roms, quizás esto me dé alguna pista del posible error

pues si, eso es una muy buena pregunta. pero tu problema inicial era el bug de los sprites, creo, y eso tp guarda una relación directa con el tema del arranque de la c-bios, digo yo, ya que suponemos que tu rom inicializa correctamente el modo gráfico que utilizas, supuesto que dices que tu programa funciona bien en un msx real y con otras bios..

saludos,
- paco
En línea
Páginas: [1] 2
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!