Karoshi MSX Community

Últimamente se ha comentado por aquí lo problemático que puede ser desarrollar juegos MSX en una plataforma u otra. Como de lo que se trata es de hacer programas que sean compatibles, esa es la gracia, con cualquier modelo, creo que sería interesante desarrollar una lista de normas de buena conducta para que a la hora de desarrollar software, se pueda garantizar su correcto funcionamiento en la mayor cantidad posible de modelos, idealmente todos.

Así a bote pronto se me ocurren los siguientes:


PARTE I

---

Versión de MSX

Es lo primero que deberiamos comprobar. Si consultamos  el valor de MSXVER ($002D) obtendremos el modelo sobre el que nos encontramos:

• 0 - MSX1
• 1 - MSX2
• 2 - MSX2+
• 3 - TR
• 4 - OCM  :D

A continuación, si no estamos sobre un MSX1 y nuestro programa lo requiere podemos afinar más la identificación consultando un par de posiciones de memoria en las que podremos encontrar información acerca de determinados usos locales para los que nuestro modelo de MSX ha sido acondicionado:
 
Estas posiciones son la $2B y la $2C. Su contenido se distribuye de la siguiente manera:


Especialmente importantes son los contenidos del bit 7 de $2B (sincronismo) y de los bits 0-3 de $2C (tipo de teclado).


RAM mínima disponible

El estandar determina que la RAM mínima disponible que puede tener un equipo de la norma es de 8Kb, ¿que significa esto?, pues que si hacemos los juegos pensando en usar 16Kb de RAM, no funcionarán en esas máquinas que sólo monten 8Kb. La decisión es nuestra, en caso de optar por la compatibilidad, deberemos ajustar nuestras necesidades a esa cantidad de memoria, que en realidad será bastante menor de 8Kb (no llegarán a 5Kb los disponibles).

Las areas de datos, en un caso o en otro deberán inicializarse como sigue:

8Kb RAM : Area de datos en RAM a partir de $E000
16Kb RAM : Area de datos en RAM a partir de $C000

Modelos MSX1 conocidos con 8Kb de RAM:

• Casio PV-7 (http://www.msxarchive.nl/pub/msx/photos/hardware/Casio_PV-7_4.jpg)

RAM máxima disponible (MSX1)/ Slots primarios) y slots secundarios (Subslots)

El Z80 o micro compatible que incorporan los MSX únicamente puede acceder a un rango de direcciones lineal comprendido entre 0 y 65535 ($FFFF), de ahí que la máxima memoria a la que puede acceder un MSX1 es de 64K (los MSX2 pueden acceder hasta a 4Mb mediante un mapper; pero eso ya es otra historia), no hay margen para más.
Estos 64Kb son lineales para la CPU; pero en realidad su disposición física puede diferir mucho de la lógica. En teoría nosotros vemos lo mismo que la CPU :


Las páginas 0 y 1 siempre están ocupadas por la BIOS y el intérprete de BASIC respectivamente, a partir de ahí el contenido de las dos siguientes dependerá de la cantidad de RAM disponible por el MSX, los equipos con 32Kb o más (¿existen equipos con 24Kb de RAM?) tendrán RAM disponible en las páginas 2 y 3 ($8000 y $C000), los equipos con 16Kb sólo en la página 3 ($C000) y los de 8Kb, igualmente en la página 3; pero a partir de $E000. Respecto a esto, es importante hacer notar que lo único que podremos asumir en un MSX al inicializarse es que en la página 3 siempre tendremos RAM.

Sin embargo, lo habitual es que un equipo MSX incorpore 64Kb, ¿donde están los otros 32Kb?. Están ahí, sólo que enmascarados por la BIOS y por el BASIC; despues de todo hemos dicho que un Z80 no puede ver más alla de 64Kb, así que si tuvieramos los 64Kb de RAM visibles, no podriamos tener al mismo tiempo ni BIOS, ni intérprete BASIC.

Esa RAM "paralela" se esconde en lo que a partir de ahora vamos a llamar slot y que físicamente corresponden, cada uno de ellos, a una ranura de cartucho (aunque no tienen porque ser accesibles por nosotros ;)).

Cuando deciamos que la disposición física puede diferir mucho de la visible lógica, nos referiamos entonces a esto:


Esta sería la disposición de la RAM en un Philips VG-8020. Según el esquema podemos comprobar como los 64Kb se encuentran en serie en el slot 3, mientras que la BIOS y el BASIC están en el slot 0 (es lo habitual). Esto podemos comprobarlo desde BASIC ejecutando:


El resultado obtenido será $F0. Este valor tendremos que interpretarlo a partir de lo siguiente:

Puerto $A8


Este resultado nos está indicando que en ese preciso instante (desde BASIC) en las páginas 2 y 3 estamos "viendo" el slot 3, que como consta en el anterior esquema contiene RAM y que en las páginas 0 y 1 vemos el slot 0, que contiene la BIOS y el BASIC,... todo en orden :)

Si queremos activar los otros 32Kb podriamos pensar que con un OUT &HA8,&HFF lo tendríamos todo arreglado; pero claro, más de uno ya habrá caido en la cuenta que desde BASIC no podemos desactivar ni la página de la BIOS, ni la del BASIC, el cuelgue sería inmediato. Para este menester será siempre necesario recurrir al código máquina; mediante una rutina como la que sigue conseguiriamos nuestro proposito de activar los 64K:


¿Y ya tendriamos los 64Kb dispuestos para ser usados?;.....pues no....:P

En el caso del Philips VG-8020 y de otros muchos modelos, si que es cierto que los 64Kb se encuentran en el mismo slot; pero la norma no especifica esto como algo de obligado cumplimiento; por lo que cada fabricante montará esas páginas de 16Kb donde más le convenga, podrán estar distribuidas al azar por cualquiera de los 4 slots. Está claro que para activar una página en concreto se hace necesaria una rutina que no se limite a aplicar una regla fija, sino que busque por todos los slots esa RAM. Ahora, como si todavía no fuera lo suficientemente complicado, entrarán en juego los slots secundarios 8o.
En el mapa de memoria del Philips podemos ver como la RAM está en el slot 3; pero hay algo más, esta aparece realmente en el 3-2, ¿que significa eso?; pues que cada uno de los slots primarios puede subdividirse en otros cuatro (0-3) llamados secundarios o subslots, estos nuevos slots no tienen representación física, se mapean únicamente a nivel lógico. Si un slot primario va a poder estar dividido o no en secundarios podemos consultarlo en las siguiente tabla de posiciones de memoria:

EXPTBL

$FCC1 - Slot 0: $80 = expandido, 0 = no expandido.
$FCC2 - Slot 1: $80 = expandido, 0 = no expandido.
$FCC3 - Slot 2: $80 = expandido, 0 = no expandido.
$FCC4 - Slot 3: $80 = expandido, 0 = no expandido.


Por culpa de todo esto, un nuevo y rápido cálculo nos muestra que de las 16 ubicaciones originales que teniamos para las páginas de 16Kb, ¡ahora podremos tener hasta 64!.
La rutina de la que hemos hablado ya no deberá unicamente buscar la RAM por los slots primarios; sino que tendrá que tener en cuenta también la existencia de los slots secundarios.

Otro ejemplo típico de manipulación de slots es el caso de las ROMs de 32Kb ($4000-$BFFF). Si nos planteamos el hacer una, hemos de tener en cuenta que la BIOS únicamente inicializará por su cuenta la página 1 ($4000-$7FFF) que es donde se encuentra la cabecera de la ROM con la dirección de ejecución de la misma. Tendremos que ser nosotros los que inicialicemos la página 2 con los 16Kb superiores de nuestra ROM y para ello tendremos que averiguar en que slot primario y secundario se encuentra. El procedimiento sería como el que sigue:

Código por Ramones/ TMHB


Con esta rutina, nuestra ROM ya estará completa en las páginas 1 y 2 y podrá ejecutarse correctamente.
 
ROMs de 48Kb (por Ramones)

Aunque las ROMs más comunes en el MSX son las de 16Kb y 32Kb (1 y 2 páginas respectivamente) tambien podemos ensamblar ROMs de 48Kb con las que tendriamos el rango completo de direcciones (64Kb) bajo nuestro control.
Son algo más complicadas que las anteriores, el principal problema es que la única página que nos quedaba disponible sin usar es la página 0 y esta página contiene la BIOS. Esto complica algo la programación, ya no sólo porque dejaremos de tener disponible la BIOS para nuestro programa, sino porque con la BIOS perderemos el ISR (Interrupt Service Routine) asociado al modo de interrupciones estandar en los MSX, el IM1, instalado a partir de la dirección $38.

Para sobrellevar esto podremos emplear ciertas estrategias como:

• Usar la página 0 como almacen de datos: para ello, tendríamos que activar nuestra página de la ROM, usar los datos allí contenidos y finalmente restaurar la BIOS. El proceso se repetiría para cada acceso que quisieramos hacer.
  Todo esto habría que hacerlo siempre con las interrupciones desactivadas, ya que como hemos dicho, en el modo IM1, el sistema trataría de ejecutar el código a partir de la dirección $38 al producirse una interrupción y en caso de suceder eso mientras que nuestra página estuviese activa, no existiría tal código y el programa se colgaría.
• Programando un nuevo ISR: tendriamos que sustituir el ISR original de la BIOS con uno nuestro en la dirección $38, de esta manera ya podríamos tener permanentemente activa esta página, que ya podría contener lo que nosotros quisieramos, código, datos o ambos.
• Cambiando el modo de interrupciones a IM2: similar al anterior, mediante este método podríamos tener permanentemente activada la página ya que las interrupciones ya no tratarían de ejecutar el código en $38, nuestro ISR se instalaría en función de los requisitos de IM2 (ver ejemplo (http://www.msxgamesbox.com/karoshi/index.php?topic=653.0) en la sección de snippets).
• Soluciones mixtas: ningún método es definitivo y en función de nuestras necesidades podremos en unos momentos tener la página permanentemente activada y en otros desactivarla para poder usar la BIOS.

En cualquier caso, la forma de acceder a esa página y de recuperar la bios, ya no puede ser realizada por las rutinas del sistema, es decir la BIOS. El MSX no cuenta con una manera de posicionar en la página de la BIOS otro slot y volver a recuperar la BIOS con otra rutina de sistema. Por eso hemos de hacerlo nosotros mismos, y para ello hay que ser conscientes y respetuosos con los slots y subslots. Lo que adjunto es un poco evolución de lo anteriormente expuesto, ya que necesitamos tener en la variable slotvar, el slot/subslot de nuestra ROM, por lo tanto estas rutinas no son funcionales si no hemos ejecutado antes la rutina search_slot.

---

FIN DE LA PARTE I

Como temas adicionales, sólo se me ocurre lo siguiente:

- No se deben utilizar modos no estándar del TMS9918/9928/9929 y compatibles. Los modos mixtos no son compatibles con TODOS los MSX1.

- Si se utiliza el modo R800 del Turbo-R, no se deben utilizar instrucciones no oficiales del Z80, porque no todas ellas son soportadas.

Y una recomendación:

- BIOS para (casi) todo.

Un fantástico trabajo, JL! Muchísimas gracias por compartirlo con nosotros en los foros.

Enhorabuena JL.  Fantástico y encima desmigajado totalmente para que nadie tenga dudas. :)

Insisto en el tema de que metamos todo esto en la web de Edu. :) Es que, no es por menospreciar lo interesante del foro en este aspecto, solo que el hilo, se morira y se perderá y luego será dificil de encontrar.

Opto mejor por dejarlo en un sitio de fácil acceso, como es una web bien preparada.

Cosas a añadir. Ya lo dices claro, los 28 ciclos de retardo para el outi, yo contaba 24 sin contar el extra de refresco de memoria, pero faltaría añadir que el problema es el mismo para OUT.

Así pues, con esos datos, tenemos que:

outi
nop
nop
outi

es correcto.

La version out(c),x es

out(c),a
nop
nop
nop
out(c),a

Basada en el mismo principio. ;)

Sobre los 50/60hz, tenemos esto en el TH del MSX2:

* International MSX



There are different kinds of MSX for various countries. The following items

are different by country:



- Keyboard arrangement, character set, PRINT USING format

- Timer interrupt frequency



The version of machine can be found by reading the ID byte information in ROM

(see Figure 2.19) and the correspondence for MSX of each country will be

accomplished (see Table 2.23).





   Figure 2.19   Contents of ID byte



-------

| 2BH |   b0  --+

-------    |  character generator

     b1   |

      |  0: Japan   1: United States, etc.

     b2   |  2: USSR

      |

     b3  --+



     b4  --+

      |  date format

     b5   |

      |  0:Y/M/D   1:M/D/Y       2:D/M/Y

     b6  --+



     b7      interrupt period (VSYNC)

         0:60Hz   1:50Hz





-------

| 2CH |   b0  --+

-------    |  keyboard

     b1   |

      |  0:Japan   1:United States, etc.

     b2   |  2:France   3:United Kingdom

      |  4:Germany   5:USSR      6:Spain

     b3  --+



     b4  --+

      |

     b5   |  information about PRINT USING

      |  or others

     b6   |

      |

     b7  --+



Lo cual quiere decir que si eso existe en MSX1 y lo miraré ahora, se puede averiguar solo mirando eso si la máquina es PAL o NTSC, mirando la direccion 2Bh, y por lo menos en las bios MSX1 que estoy mirando si se cumple. :) Y espera, que me pase a papel el TH del MSX1 de la página de Edu ... sip, 2Bh, en efecto te dice si la máquina es PAL o NTSC. :)

Sobre los slots... si habría que añadir, aunque fuese la rutina básica para posicionar de tu rom, si ejecuta en 04000h o 08000h (lo más normal) los otros 16k, aunque también están en el TH del MSX1 y del MSX2 con rutinas llamadas "where_am_I" que me hacen gracia en estos momentos. :)

Muy currado, JL :)
Creo que habria añadir tb el tema PSG, y su registro 7 de la muerte.

Excelente idea y trabajo, JL! Sugiero que esto quede pegado arriba, siempre a la vista. Y si pudiese ser que el primer mensaje se fuese editando para incluir las sucesivas aportaciones sería redondo. Y lo de que se recoja en otros lados también. Nunca está de más tener las cosas importantes en más de un sitio, que ya sabemos lo que pasa, que un día peta el servidor y no hay copias y tal...



<modo pejiguero/on> ( y más o menos OT)
Ya que esto va de corrección técnica será mejor decir que es 50Hz ó 60Hz. Es muy común eso de cambiar de PAL a NTSC o viceversa, y no es correcto. Se cambia la frecuencia pero no la norma. Será PAL/50Hz ó PAL/60Hz y NTSC/60Hz ó NTSC/50Hz. La norma de Brasil, por ejemplo, es un PAL a 60Hz. En Francia es a 50Hz pero SECAM... (bueno, no exactamente, porque SECAM es un poco coñazo y por eso los aparatos franceses traen salida RGB y tal, pero bueno... :P)
Perdón por el rollo, pero es algo que no se por qué no me gusta. Ya veis, cada uno tenemos lo nuestro  :P ::) ;) ;D
<modo pejiguero/off>

un saludo.

Además tienes razón. El bit solo indica el refresco. Lo de PAL y NTSC es una costumbre mal adquirida, que incluso veo en el manual (TH) del 9938.

Bueno, podemos averiguar el refresco, hablemos como toca. ;)

No sé en qué momento el registro 7 llegó a suponer la muerte ... Gracias de todos modos por hablar de esto de este modo MsxKun. Sin duda habrá quien diga que este tema me resulta algo personal ... Pues claro que sí, y si dijera que no mentiría como un bellaco. Pero la verdad es que no veo la gravedad y el bochorno que se le da.

Mi rutina para detectar versión en Beepertron (venga, ahora podéis rajar):

Interesante thread!! (ya mismo es un sticky thread para que no se pierda ni nada por los infinitas lindes de los foros Karoshieros  ;) ::) )

Por cierto, Jl, te pediría que todos los cambios, sugerencias, etc... que creas oportuno modificar, alterar y demás, hazlo en el primer mensaje del hilo, para así dejar el documento al 100% de su lectura en el principio, y que la gente no tenga que leerse todas las sugerencias/cambios separaditas en todo el hilo.

Again, fantástico trabajo JL!, ya te queda menos para cambiar de categoría de user  :D :D :D :D! (si es que siempre te nos adelantas...)

Una de slots y subslots rapidita. Lo básico para hacer una Rom de 32k y de 48k, normal de ASM/C. Dejo al margen las de Basic, puesto que no tengo conocimientos sobre ellas, y hay información en otras páginas (que lo ponga aquí quien más sepa de ellas).

Esto sacado de los TH. Las Roms pueden ser inicializadas tanto en la pagina 0, 1 y 2 del Z80. Dejo al margen las de pagina 0 pues son algo raritas, aunque tenemos casos donde se usaron (Hero, Crazy Train...).

Las de pagina 1 y 2, es decir, 04000h-7FFFh, y 08000h-0BFFFh, son inicializadas por el MSX. El MSX detecta la cabeceza 041h,042h, coge la dirección contenida en 04002h, o 08002h, posiciona ese slot/subslot y ejecuta. Pero no podemos dar por hecho que las otras 16k estén posicionadas, pues la BIOS no lo hace.

Por ello, ya que las vamos a utilizar, es necesario saber en que slot/subslot estamos y posicionar esas 16k Extra. Esto se realiza con esta pequeña rutina ASM, repito, contenida en THs.

Adjunto pequeño programa inicializador, también explicado en los TH, que crea una Rom arrancable en pagina 1, y busca las 16k extra (08000h-0BFFFh), y las posiciona.



Y ahora hablemos de las Roms de 48k. Estas Roms, perfectamente legales, cuentan con un problema: Las 16 extra utilizadas se posicionan en la misma zona del Z80 que la BIOS. Esto nos complica la programación, y contamos con algunas maneras de usarlas:

[] Como almacen de datos: Posicionamos la pagina de la Rom, usamos los datos, y volvemos a poner la BIOS. Siempre con las INTERRUPCIONES DESACTIVADAS, ya que en el modo IM1, el sistema salta a 038h cuando se produce una interrupción y podría destrozarnos el programa.

[] Con código propio. Pero hemos, o bien cambiar el modo de interrupción a IM2 (cosa que funciona pero no se hasta que punto es standard), o bien creamos nuestra propia rutina de control de interrupciones. 038h en adelante.

[] Un poco de ambos.

En cualquier caso, la forma de acceder a esa página y de recuperar la bios, ya no puede ser realizada por las rutinas del sistema, es decir la BIOS. El MSX no cuenta con una manera de posicionar en la página de la BIOS otro slot y volver a recuperar la BIOS con otra rutina de sistema. Por eso hemos de hacerlo nosotros mismos, y para ello hay que ser conscientes y respetuosos con los slots y subslots. Lo que adjunto es un poco evolución de lo anteriormente expuesto, ya que necesitamos tener en la variable slotvar, el slot/subslot de nuestra Rom, por lo tanto estas rutinas no son funcionales si no hemos ejecutado antes la rutina search_slot.



Repito. Cuando accedais a esa página, aseguraros que teneis las interrupciones desactivadas, o bien, cuando está posicionada no se os ocurra activarlas, a no ser que conteis con vuestro propio interrupt handler.

Ale, si algo no queda claro, lo puedo extender un poco, pero para empezar creo que es suficiente.

Que no lo decia de mala fe, hombre  :)
Lo llamo de la muerte precisamente por eso, pq en teoria era el Armaggedon del MSX, que lo hacia explotar y todo eso. En realidad, a nadie le ha ocurrido, y ya esta. Se coló el registro, y nadie de los que usamos el replayer tampoco nos dimos cuenta, asi que no hay por que decir que fuera culpa tuya. Yo, al ignorar que ni existia eso, lo use. Culpa mia por ignorante, de usarlo, en mi caso.
No hay que darle mas vueltas, como tu dices, se le dio demasiada gravedad. No hay problema, ya esta solucionado y ahora se puede tener en cuenta. Pero esta bien que para aquellos que en aquel entonces no estuvieran por aqui o quienes vieran este post si se cuelga en la web y no sepan de que va el tema, esten alerta con el.
Aun asi para mi siempre sera el registro de la muerte ;)  Pero en el buen sentido.

M... y que hay de la rutina CALSLT ($001c)?
La he probado y parecer funcionar, pero claro, puedo estar metiendo la pata, pa variar  :P

En absoluto, no metes la pata. Pero CALSTL vale para llamar a una subrutina contenida en cualquier slot/subslot.

Lo que explicaba es como disponer de toda la página completa para tratar los datos y recuperar despues la BIOS de nuevo. ;)

Lo tuyo es correcto y funciona. :)

Ahora veo, asi te ahorras tener que tener alguna rutina en pag0 a la cual saltar, por pequeña que sea... Conectas y catapumchimbola, tienes datos y haces. Pillao :)

Hi friends, I would point out a recommendation
for PSG register 7: the two most significant bits
affect the joystick connection order, and must
not be involuntarily altered.

That means, if you want to write a binary
value B to reg 7 in ASM, try something like
this:

A=reg(7)
reg(7)=(A AND 11000000b) OR (B AND 00111111b)

Otherwise, you could find joysticks not responding
or exchanged. This is usually not visible on many
emulators, but only on real MSXes.

My best regards,

Andrea

Bueno, en cuanto pueda y se me enfríen las yemas de los dedos ire actualizando el primer mensaje con vuestras aportaciones. Lo primero, gracias a Ramones por redactar ese texto y ejemplos de uso de slots y página 0, lo incluiré citando al autor :). Totalmente cierto el lapsus del PAL/NTSC/50/60, en todo caso se ha de hablar realmente de 50/60Hz, que es lo que realmente determina la disponibilidad del VDP en cada refresco. También trataré de incluir el tema de los modos mixtos y el uso de instrucciones no oficiales del Z80.

Respecto al PSG#7, no creo que deba ser incluido aquí ya que no se trata de un tema de compatibilidad entre máquinas, es simplemente de una cuestión de no debe de hacerse en ninguna máquina, sea de la generación que sea. Si se investigase un poco más el origen de esa recomendación hecha por los creadores de hardware igual habría tema para hacer un pequeño artículo...


Hey, Andrea, thanks for your info! :) ; but right now I believe that since the infamous PSG#7 affaire, this problem is a very well-known one ::). Anyway I found interesting the last bit of your post; you say that misusing the register could lead to swapped or even non working joysticks. Have you found the info somewhere or maybe do you have electronic knowledge of what happens if you output incorrect data?

Thanks again! ;)

Ahora pondré una inicialización de PSG (para callarlo), pero una cosa te puedo decir sobre tocar esos bits. Matar máquinas, pues hombre, no he visto que mate ninguna, pero si que produce un efecto negativo: En algunos ordenadores (me pasaba en el 2+), los Joysticks dejan de funcionar si toquiteas y cambias esos dos bits altos, como comentas en tu mensaje.

Así pues, no es que sea tema o no sea tema de incompatibilidad, es tema de que si los tocas, además de matar MSX (que sigo flipando con eso), si dejan de funcionar algunas partes de las que controla el PSG. En el 2+ los joysticks y en otro, pues vete tu a saber. Y como se puede evitar, con un código bien sencillito, pues lo evitamos y ya está. Y vale para todos los MSX.

Por lo tanto lo suyo es no tocarlos nunca, y es tan sencillo como enmascarar siempre que escribamos en el mixer, como se ha dicho ya por aquí.


Y ya puestos, pasando a ASM lo que escribia Andrea:


Y bueno ya estoy preparando lo del disco. :)

Ah, otra rutina que he mandado a algunas personas aunque han pasado de ella. XD Esto es para el tema VDP, una rutina de trasnferencia masiva de datos, valida para VBL o no, y con cualquier número de datos.  (logicamente para pocos datos es lenta, y por ser válida para cualquier cantidad sin múltiplos y demás, pues tambien es lenta).

----------------------
vdp_reg98 y 99 los leo en otro sitio al principio de mis programas, son dos variables, con los datos de la BIOS, ya hay por ahí más ejemplos.




Se puede mejorar el initvram para ahorrar unos ciclos y también cambiando el orden de los parámetros de entrada se puede evitar alguna instrucción, pero bueno, no os lo voy a dar todo hecho. ;)

Y si, yo pondría todo al principio ordenado por tipo (vram, psg, slot), y que quedasen esos mensajes siempre los primeros. ¿Es posible Jon?









 

Ola todos,

  and thanks Ramones  ;D for your much cleaner explanation
of what I meant.

  I fully agree, this is *not* an incompatibility between MSXes,
as it is part of the standard (I found some details in Konamiman's
MSXTH, chapter 5, section about PSG reg 7).

  But I thought it would be a useful mention, as this is often
an incompatibility between emulators and real MSXes, and
an easily forgotten detail; on my VG8010, joysticks 1 and 2
exchange or one stops working if wrong bits are set, which
is rather bad if you are playing a 2 player - 2 joysticks game...

  Bye friends,

                                                                  Andrea



 

Thanks. If you have a look at this (http://www.msxgamesbox.com/karoshi/index.php?PHPSESSID=a3f2f3ff96f90258b5b9bcac1e62513e&topic=73.0) you'll see this problem was solved a year ago or so, when the problem was detected.

El problema Dioniso, o mejor dicho, lo que se busca con este hilo, no es saber si se ha detectado y solucionado en players como PT3, si no, conseguir que la gente no lo cometa nunca más. :)

Digamos que la propuesta de este hilo es algo así como "programar con educación". :) Konamiman estaría orgulloso de nosotros. :P

Lo sé Ramones. Lo que digo es que en enero de 2006 el tema del registro 7 del AY-3-8910 causó muuucho revuelo y si algo tiene claro la gente es que hay que enmascarar los bits sexto y séptimo de susodicho registro.

Tan sólo echa un ojo a cualquier post de cualquier fórum cuando se habla del PSG ... siempre, siempre, siempre sale este tema. Esto lo digo sin malos rollos. Por eso digo que es un tema que hoy día está super rallado y es algo archiconocido.

Tema aparte:
Te mentiría si te dijera que no me toca un poco los mismos, cuando alguien hace comentarios jocosos al respecto; sobre todo porque le he dedicado mucho tiempo al tema y lo sigo haciendo y a veces pienso que no merece la pena (de hecho, en un momento de ralladura total, de sentirme vacío, un hazmereír, la noche del viernes borré todos mis posts del tema de desarrollo de un replayer PT3 más corto -1696 bytes- ). Es un año ya aguantando el mismo rollo y todo tiene un límite.

No quiero salpicarle mielda a Edu. Pero nadie ha dicho nada sobre el fallo de su replayer con el registro 7; léase, en Malaika. Jon lo arregló, actualizó la ROM y punto. La gente sólo recuerda al primer hombre que pisó la luna (o, en este caso, al primer hombre que pisó una mierda en la luna).

Bueno, Dioniso. :)

No te lo tomes a mal, en mi caso JAMAS he intentado que cuando hablo del tema sea una "pulla" indirecta hacia a ti.

Para que veas que no eres el único que pecaste de pardillo en este ejemplo, te puedo decir que la primera versión de Dahku tenía el bug. :) Sip, como suena, yo mismo cometí la estupidez en mi replayer de PT3, y quizás en mi caso es MAS GRAVE que en los vuestros.

Me explico, yo *vendía* Dahku y si encima mataba un MSX, pues menuda cagada por mi parte, una vergüenza MUY GRANDE, y todo por culpa de no testear bien el tema de joystick en el 2+.  :-[

Además, aquello ya pasó no le des más vueltas. Ya sabes, que encima yo estoy contigo. Se pasaron 4 pueblos, ya que no fue correcto atacar eso, y NO atacar a escrituras incorrectas en el VDP como las que acusan algunos juegos de ese Dev. Es decir, si se ataca una cosa, se ataca TODO lo que no es standard.  Es que precisamente el programa que ganó el concurso, escribe en 99 y 98, y ya me he hartado de decir que esto es correcto en MSX2 (lo dice el TH), pero en MSX1 NO LO ES.

En cualquier caso, repito lo mismo. Hay que apuntar esto y tenerlo presente para futuros Devs. De los errores se aprende, y al fin y al cabo Dev es un concurso sin ánimo de lucro.

Ahora, con este hilo, que sería interesante pasar a inglés todo o dejar ordenadito en una web, nadie tiene excusa para no hacerlo  como toca. :)

Y no te cortes con lo del PT3. Sería superinteresante dejarlo por aquí. A ver si termino lo que estoy preparando de teclado/joystick ... es que le Coche Fantástico me ha quitado una hora de programación. ;)

Lo sé, lo sé. No lo decía por ti. Tan sólo me molesta que se hagan comentarios jocosos al respecto (no al principio, pero llega un momento ...)


Bueno, hasta diciembre 2005 / enero 2006 este tema era "desconocido". Mucha gente hizo demos, replayers bajo DOS y BASIC y juegos y nadie se dio cuenta ... tampoco estalló ningún MSX como se decía que podía pasar  ::)



Seguimos totalmente de acuerdo. Y gracias.


Claro. Aquí (http://www.geocities.com/dioniso072/PT3_Replayer_1696_bytes_long.zip)tienes/tenéis el archivo de 1696 bytes.

Ale, JL, lo siento, más faena para ti. :)

Aquí van unos ejemplillos de lectura de teclas y joystick, que seguro que también son interesantes. Lo dejo todo en un LZH, con la Rom de ejemplo ensamblada.  Abajo el código de la misma.

--------------------------------------------------
KEYBOARD / JOYSTICK
-------------------


Aquí van un ejemplo completito de como usar el teclado y el joystick. Este tema es un poco "duro", desde el punto de vista que existen muchas maneras de hacerlo, y además puede ser algo "no standard" cuando hablamos de algunas teclas.

Básicamente, existen muchos tipos de teclado en el ámbito del MSX. No todas las teclas están posicionadas en la misma fila/columna en todos los MSX. Pero cuando hablamos de las teclas comunmente utilizadas en los juegos, si tenemos una misma correspondencia.

Así pues el ejemplo nos demuestra como usar ambos joysticks, el teclado, formas de leer una tecla continuamente y esperar a que el player suelte, y además dos formas de leer el buffer del teclado, con y sin BIOS.

También podemos encontrar en MSX ASSEMBLY (http://map.tni.nl/), un interesante artículo del problema de algunos teclados MSX, que "autopulsan" teclas con la combinación de otras.

Breve explicación del programa.

INITMAIN:

Inicializa la Rom, de una forma sobradamente conocida, posiciona Screen 0 con 40 columnas y unos colores para poder escribir texto y que sea visible. Elimina el keyclick, obliga a la rutina OUTDO a escribir en pantalla e inicializa los textos.

También hace una lectura forzada de teclado para inicializar los bufferes de teclado, y seguidamente espera a que se produzca una interrupción para rellenar adecuadamente el buffer de teclado antiguo.

MAIN:

El bucle principal no tiene mucho misterio. En cada interrupción revisa si hemos pulsado/soltado:

a) Cualquier tecla, y mantiene a 1 hasta que no se suelta
b) Cualquier tecla, y solo mantiene a 1 durante una interrupción. No se volvera a poner a uno hasta que no soltemos y pulsemos de nuevo
c) El boton 1 de Joystick y SPACE, se pondrá a 1 solo cuando pulsemos y soltemos. Mientras no soltemos no se pondrá a 0.
d) Idem con boton 2 Joystick y CTRL, solo que siempre estará pulsado hasta que no soltemos.

Por ultimo imprime los resultados de esa interrupción, espera a que se produzca una nueva interrupción y relee los buffers de teclado.

PANTALLITA:

Esta parte no creo que sea necesaria de explicar. Son unas rutinas rapiditas para imprimir en pantalla con la BIOS.

KEYBOARD AND JOY SUBR:

Aquí empieza la "chicha".

[] Presskey: Activará el flag Cy, si alguna tecla ha sido pulsada o está pulsada.

[] PressKeyTrigger: Activará el flag Cy si alguna tecla es pulsada, pero no lo activará de nuevo hasta que no sea soltada y vuelta a pulsar.

[] CheckFire: Aunque no se usa en los ejemplos, activa el flag Cy cuando el boton 1 del Joystick, Shift, Space, TAB y Return están pulsados. Una manera de tener más de un botón de fuego en nuestras aplicaciones, y evitar el "sobreuso" de SPACE.

[] CheckFireTrigger: Idem que el anterior, peeero, solo se activa el flag Cy, si se pulsa, se suelta y se vuelve a pulsar.

[] CheckFiretrigger2: Para botón 2 de Joystick, CTRL y GRAPH, con "trigger".

Aquí faltaría añadir la rutina Checkfire2, para saber si esta pulsado en cada interrupción sin soltar. :) La dejo como ejercicio.


[] CheckfireTriggerall: Pues para saber si cualquier boton de fuego, 1 o 2, de cualquier joystick y teclado esta pulsado y se suelta y se vuelve a pulsar.


[] TECLADO: Esta rutina se ha de llamar al principio de cada interrupción. El hacerlo así es para poder aprovechar las teclas leídas de la BIOS, en caso de usar ese modo. En caso de usar el modo manual, pues lee el teclado. Básicamente lo que hace es pasar el buffer actual a viejo, leer el nuevo teclado y leer los joysticks.

[] JOYSTICK Y JOYSTICK2:

Una manera muy curiosa de leer los joysticks, y aprovecharlos para el mismo player, ya que el ejemplo sería funcionar para un juego de 1 jugador. Lo que hacen estas rutinas, además de leer ambos joysticks (PORT 1 Y 2), es aprovechar el buffer de teclado para marcar si ha sido pulsado alguno de los botones, y las direcciones. De esta manera nuestro bucle principal solo lee "teclas", y no necesita leer teclado por un lado y joysticks por otro lado.

[] READKEYBOARD: Esta rutina solo se ensambla si usamos el modo de lectura de teclado NO BIOS. Basicamente lee todas las filas de teclado y las almacena en keys.

[] TECLAOLD: La madre del cordero. :) Le pasamos en A la fila que deseamos consultar con "trigger". Es decir que solo nos devolverá que una tecla de esa fila ha sido pulsada, en caso de que estuviese soltada. Si en el antiguo frame estaba pulsada la devuelve como no pulsada. :)

NOTAS FINALES:

Para finalizar, comentar que el programa tiene dos maneras de leer el teclado, aunque ya se ha explicado por encima en las descripciones de las rutinas. Normalmente si hacemos una Rom y no "jugueteamos" con pilas y punteros, la rutina de 38h nos lee automáticamente el buffer del teclado, cual rutina "readkeyboard".  Si la BIOS lo hace, y ya que normalmente salta a 38h, ¿por qué hacerlo nosotros? ;)

El modo "sin bios", es muy recomendable para de todo tipo que parcheen completamente la rutina de interrupción.

Dioniso, siento si he molestado con el comentario :( Como he dicho, por mucho que se montara, no vi ni veo el error tan grave (como ha dicho Andrea, solo le ha pasado que le intercambiaba joystciks, NO que rompiera nada) y por eso me lo tomo mas a la ligera. Y tampoco pensaba que a estas alturas aun afectara. Aun asi, no volvere a referirme al tema, y te pido perdon, en serio. Es que no suelo tomarme la vida tan en serio, bastante mierda es ya como para hacerla mas dura. Sigue con el trabajo PT3 (y 1bit, y demas), que es muy bueno. Animo payo :)

P.D.: Creo que he puesto algun quote de mas  :-\ ?

Las 1000 primeras veces sí me hizo gracia.

No te preocupes, sé que no había maldad en tu comentario. No sé si has comprendido por qué me molesta "ahora".

Pues no  ???

Que se ha transformado en una coletilla cuando se habla del PSG. Que tú y otros no lo decís con maldad pero que tras 1000 veces ya no me hace tanta gracia y me jode. Que se me quitan las ganas de hacer nada para vosotros. Que intento ayudar y todo sale siempre alrevés. Lo entiendes ahora?

No sé, me estoy empezando a rallar. Mejor dejamos el tema por ahora. La verdad es que se han juntado muchas cosas; de mi vida real y de esta otra ... A veces vengo aquí para evadirme y ... en fin, el resto ya lo has podido ver.

Entendido y dejado, solo recuerda que algunos podemos tener musica gracias a ti. :). Venga, espero que esas cosillas que dices tiren para el lado bueno, ok?

Gracias.

En el caso del Caruso, el problema es de inicialización :'(. Es decir, para eliminar el "problema", era tan fácil como llenar de "0"s la zona de RAM destinada a las variables del raplayer antes de inicailizar el mismo (cosa que se me olvidó hacer en el Malaika. Por lo demás, estoy de acuerdo con los comentarios en este hilo acerca de que fué exagerado todo lo que ocurrió el año pasado... pero no creo que nadie siga hablando de ello y apuntántode a ti por el error, Dioniso: y si hay alguien, solo dime a quien hay que matar  2gf:)

Yo solo espero que sigas en la cresta de la ola y que nos regales un nuevo juego con la misma calidad del Magical Stones!. Por cierto, el TT-Virus es un proyecto abandonado, o podremos ver la luz del mismo??  ;)

Un abrazo, Alfonso!

@Ramones: MUY util! me lo agencio. :o

@Dioniso, be water my friend! y ahora que menciona Jon el proyecto del TT-Virus, la verdad es que se abandonó por fata de tiempo viendo que no llegariamos a tiempo para la Dev pero perfectamente podríamos retomarlo pero no se cuanto tiempo tomaría y si las espectativas iniciales en el sentido de ver cosas nuevas en un MSX se podrían cumplir ...y mas despues de leer este hilo.

@Jon: y una version extendida del Phantomas? para mi que el mapeado se quedó corto  ;D

Dios mío! Claro que se pueden ver cosas nuevas! Siempre! Tan sólo falta motivación. Mi pregunta es muy sencilla: quieres, de verdad, hacer el juego o no? Piénsalo bien y escríbeme por privado. Yo, como siempre, estoy dispuesto.

Pues anda que no me sobró sitio en los 32kb... pero, antes de mutar un juego que ya está hecho, prefiero meterme en otros berenjenales. Anda que no tengo ganas de terminar definitivamente el Malaika y machacar el Speedjet Racers de una vez...

Tal vez le podamos hacer una sugerencia en cuanto al tamaño del mapeado cuando na th an se meta con el Salem  ;)

Ahí va mi pequeña aportación que he aprendido con el Word Invaders. Según el THB, la variable CAPST (FCABH, 1) controla el estado de la tecla CAP de la siguiente forma:


Sin embargo en BIOS no europeas es incorrecto, ya que sólo el valor 255 hace que se considere como encendido el valor de CAP. ¡Pero aún hay más! En las BIOS europeas si tocamos el valor de CAPST, por mucho que pulsemos CAPS no va a pasar nada, ya que el valor no cambiará (al menos así parece pasar), pero en otras BIOS sí que cambia.

¿Cómo solucionarlo?

Si queremos tener las mayúsculas siempre activas habrá que poner el valor 255 en CAPST en cada interrupción, de forma que al leer el teclado se tenga en cuenta este valor.

Saludos
--
Sph.

¡Leshe, pues es verdad!, se me olvidó comentarlo... :P. Nada, mejor, así se adjunta con el bloque de gestión del teclado de Ramones :)

 Interesante tarea de documentación Jose Luis, pero sería de interés que además de indicar la bibliografía dijeras en que punto se encuentra lo que dices, ya que hay veces que los autores redactan comentarios, opiniones, ejemplos, etc, que puede ser interesante.


 En relación a lo de Alfonso pués, que no te preocupes. Se sabe lo que aportas desde hace tiempo, sobretodo en sonido, y si no funciona o lo que sea, ¿que?.


 Pués eso. De todas formas no he observado el error relacionado con tu nombre. Se habla del error, y ya está. Igual hay algo más no lo sé.

 Saludos Alfonso.
 

Sigue la discusión en otro topic!: http://www.msxgamesbox.com/karoshi/index.php?topic=668.0