Karoshi MSX Community

Hablando ahora con QUIBUS en el canal #msx de rizon, me ha dicho que ha encontrado un BUG en el PT3 player...

http://sourceforge.net/tracker/?func=detail&atid=421861&aid=1390211&group_id=38274

Asi que musicos de PT3 de varios juegos de por aquí, miraoslo ;)

Un saludo,

Salva

"Would it be possible to make openMSX give a big flashy warning when a program writes these hazardous values to R#7? It's known to cause hardware crashes and possible permanent damage."

O.o

Bueno, históricamente es lo que se ha comentado siempre; pero me da la impresión de que no le ha pasado a mucha gente (a lo de cascar MSX, me refiero). De hecho a mi me funcionaban TODOS los puertos de joystick en TODOS mis MSX, uno de cada generación. Está claro que he estado jugando con la muerte... :P

En fin, es fácil de corregir. Posiblemente hoy o mañana prepararé una nueva versión del "Caverns" con ese fallo eliminado y de paso ¡con un nuevo sistema de sfx que sustituye al (inexistente) previo, gracias a la inestimable colaboración de Wyz!. ¡Yay!  :D

No indica si con el Parachuteless ha tenido el mismo problema o no (tb usa PT3), aunque yo lo probe en MSX1 durante toda la ru (osea que tiene chip de sonido, no esta en el msx-engine) y no hacia na raro.
Tampoco en pruebas posteriores... Alguna forma de verificarlo seguro?  ???

En cuanto a lo de corregirlo, seria modificar el replayer de PT3? Como y donde?  :-\

Ains... esto pasa por no usar el Caruso! :)

Sustituyendo la rutina ROUT por esta otra :


...corriges el problema. No se si habrá algún otro método más práctico; pero a mi me vale...

Para probarlo, si se supone que con el OpenMSX podían dar problemas los joysticks 1 y 2 (si el Parachuteless sólo usa teclado pues nada...) tienes ejecutarlo con un joystick virtual pinchado. Modifica lo siguiente :

Al final del archivo C:\Documents and Settings\<usuario>\Mis Documentos\OpenMSX\share\settings.xml


Puedes dejarlo como está; pero yo prefiero estas teclas para no confundirme con el stick 0, los cursores.

Una vez modificado, arranca el OpenMSX y en la consola (F10) teclea plug joyporta keyjoystick. Ahora se supone que has pinchado un joystick en el puerto 1, funciona con O,P,Q,A (si modificaste el settings.xml). Prueba el juego y si va bien, repite el proceso con el puerto 2, introduciendo en la consola unplug joyporta y plug joyportb keyjoystick. Si no te ha dado problemas durante un par de partidas y meterte por menús, pues eso es que está bien.

Lo único que hay que hacer es enmascarar los valores que se escriben al registro 7 puesto que estos valores no deberían pasar de 63 (%xx000000, no creo que haga falta explicar qué hacen estos bits). El "problema", a mí ya me han estallado 5 ordenadores (a veces la gente es increíble), es que el valor creado por el PT3 player para el registro 7 siempre escribirá el valor 0 en los dos bits más altos del registro 7. No es la forma correcta, pero tampoco supone un problema. A mí siempre me ha funcionado. Me ha bastado colocar 2 NOPs tras leer el joystick a pelo para que el valor sea el adecuado o ninguno si leo el joystick desde la BIOS. El Magical Stones 16k utiliza el PT3 player sin más, ha sido testeado en MSX1, MSX2, Turbo-R. No comprendo el alboroto.

JLTursan hace lo correcto, aunque no sé si el valor a escribir debería ser siempre %10xxxxxx. Lo totalmente correcto, en cualquier rutina de sonido que maneje el registro 7 (es decir, todas) sería:

1-leer el registro 7 directamente del PSG.
2-enmascarar los dos bits más altos del valor que vayamos a escribir (valor que SÓLO debe utilizar los 6 primeros bits) con los obtenidos de leer el registro 7.
3-enviar el valor ya enmascarado al registro 7.

La rutina del PT3 player, al igual que muchas otras, lo hacen de la forma más rápida posible, de eso se trata. Si fallara, obviamente, no habría que utilizarla. Pero el único fallo real viene en la teoría (no se debería hacer pero funciona perfectamente) y no sé si en algún emu. Para mí, un emu es algo muy práctico, muchísimo, pero NO es un MSX. Joder ... me estoy poniendo nervioso. Me acuerdo ahora de cuando MATRA puso el modo mixto en sus juegos y no iban en los emus. Fue aquello un fallo? Ellos se jactaban de que no funcionara el los emus y si en los MSX. Y el Seleniak? Esto sólo muestra las barreras entre los MSXs y los emus, que cada vez están más cerca. Un emu es un MSX pero sin magia.

Bueno, un saludo. Parece que el PT3 player es una cosa mala. Vaya mxxrda de primer mensaje que he publicado en el fórum.

Nah, ni de coña. :P

Por lo que parece el jurado se ha propuesto destripar (y lo digo literalmente porque según parece han desensamblado código) todos los juegos y en cuanto encuentren el más mínimo problema lo van a sacar a la luz (lo cual no me parece mal).

En mi juego hago una lectura secuencial de los sticks 0,1 y 2. Cualquier joystick conectado debería funcionar; pero al escribir en PSG#7 valores del tipo 00xxxxxx lo que está pasando es que el joystick 2 se va al carajo...

Del Technical handbook :


Ese bit 7 es el que se va al carajo.

Lo que no entiendo es como en los emuladores esto falla y en los MSX no pasaba nada de nada. EL joystick 2 funcionaba bien (o por lo menos en el NMS8245 y con un pad de la megadrive, que es el que recuerdo fijo).

Bueno, lo dicho, que no tiene importancia.  :)

Editado: Acabo de darme cuenta que en el TH está mal explicado; así que corrijo la cita del texto con los valores correctos para los bits 6 y 7... :(

Osea que valdría un simple:

;

Si suponemos que el bit 0 va a llegar siempre a 0, sí; pero en el reporte del bug aseguraron que al PSG#7 le había llegado un $56  ???
Así pues, como más vale prevenir que curar, enmascaro los dos bits y fuera problemas.  :)

Realmente dicen 56, no $56 y estoy de acuerdo con que es muy extraño que funcione bien en los MSX reales y no en el emulador, a mí me ha funcionado bien en mi MSX1 y en la RU ambos juegos han estado funcionando en un 8235 con joystick, por lo que no entiendo el alboroto...

El finde tendreis una versión fixeada.

En fin...
--
SapphiRe

Pues mirare todo ello lueg en casa a ver, aunque a ver si encuentro ese cacho codigo en el que use yo, porque no podia compilar la version "normal" y me pasaron una rara con todo de etiquetas TC000algo, etc....
Y sip, Joe va con Joystick1 o Cursores indistintamente. 
Mirare de hacer las pruebas en el OpenMSX a ver que opina. Menos mal que es el open, pq si fuera el BlueMSX lo llevo claro, en mi carraca de pc va fatalmal de lento.

En general no creo q haya demasiado problema con el susodicho registro, pero sip, es mejor asegurarse y ya esta.
Gracias por toda la info!  :D

Ah, pues es verdad  ::)
Bueno, pelillos a la mar, como ya he dicho más vale prevenir que curar (total por un mísero AND).

Yo en el lugar del ROUT tengo esto, que parece ser el equivalente:


Digo yo que sera ahi. El codigo es diferente, pero es que el normal no me compilaba.


De cosa mala nada :)
Respecto al valor %10xxxxxx, segun el Handbook suele ser asi, aunque supongo que habria quien lo podria querer al reves. En todo caso, si al final resulta que es %00xxxxxx, eso significa que los dos puertos son de In, no? Si solo usas un puerto para entrada, da igual que el otro sea In o Out pq no vas a outputarle nada no? O confundo un tipo de puertos con otro? :S

Sea como sea, he probado el Parachuteless en el debugger del NO$MSX, que te indica los valores de todos los registros del PSG (entre otros) y efectivamente el bit7 se va al garete...

Mirare de corregirlo tb en el listado ASM de arriba, pero me iria mal que ocupara mas de 4 bytes de los que ya ocupaba antes... :D

Una ultima cosilla...

Aqui en el cacho del mute al registro 7 tb le llegara un cerapio, por lo tanto el bit 7 sera 0:


Nop?

Sip

¡Caray!, eso si que es hacerle un mute al PSG...todito a 0.

¿Por que no pruebas la rutina convertida por Dioniso?, no creo que te lleve más de unos minutos sustituirla y parece mucho más elegante que la que usas actualmente... :)

Es que deberia ser la misma, aunque parece que no del todo. :D Creo que me la envio el mismo al no poder compilar la otra con el TniASM (se encasquillaba en el chorro tablas raras). Al final lo he cambiado en la misma que ya esta, al estar cada out por cada registro todos seguidos, y encima en el registro 7 le pasa el valor a A (no se pq), pues he aprovechado y le he añadido el and y el or y eso son justos los 4 bytes que podia gastar :)

Comprobando en el NO$MSX me indica que el valor del registro 7 ya no pierde el byte 7 :) (para ser mas exactos, que siempre es 1).

En cuanto a lo de mutear a saco, ya mirare como esta en la otra rutina y ya mirare si lo dejo asi o que, total, poco rato esta muteado, siempre suena algo...

Tb he probao los cambios en el MSX y aun rula la rom :) Con joystick y todo. Probare mas, que no hay prisa, y si todo va bien, pues ya colgare el Parachuteless Joe Service Pack 1.  ;D

Así estamos todos, emulando a Micro$oft.  :P

Bueno pos ya he hecho el arreglo y lo he probado en el OpenMSX. Antes efectivamente dejaba de ir el joy1 para irse al 2, y ahora va bien, se queda quietecito en el 1.
Ahora bien, he hecho pruebas de todo tipo, hasta haciendo el pino y cuando solo dejo el arreglo en el replayer pt3 y no en los efectos de sonido (rusticos, escrituras con WRTPSG y punto), funciona bien, y eso que el registro 7 suele ponerse a 53 (no hex$), por lo tanto el susodicho bit sigue siendo 0. Pero aun asi funciona bien.

En cambio si toco ahi tb y dejo el bit a 1, va bien, pero al sonar el sonido me enciende el led de Kana (esto en el TR). Asi que como eso me mosquea bastante, he dejao los sonidos tal que estaban, ya que funciona bien.

Aun asi, cuando se pega el piño tb se enciende la luz del Kana pero que le den. :P

Bueno, si lo veis bien asi mando a Edu el SP1.  ;D

Mola, puedes incluir un anexo en las instrucciones indicando que en los TR el piñazo de Joe puede provocar que se encienda el led de Kana... ;D ;D

 ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

Pues he mirao el janbuc y el led del kana esta controlado por el bit 7 del registro 15 del psg... Asi que mirare pq se cambia si en teoria yo no lo toco...
Al final siempre se aprende algo :)

Pues si encuentras algo ya sabes, porque al parecer con el Caverns pasa algo parecido (ni me había dado cuenta  ???) y yo tampoco, lo juro por mis encias, toco el PSG#15, de hecho lo he comprobado y la rutina ROUT no llega al 15, ¿quien lo toca pues...? :P

Encontrado (al fin). Parece que al menos en mi caso, mandaba sin querer un valor a un registro bastante  mayor que el 15 (por lo tanto inexistente) y el psg decia Ein? Solucionado esto, verificado (esta vez si!) que no hay valores raros, ahora va bien y no se enciende el Kana :)  Mira a ver si te escojonaba algun valor perdido por ahi, por ej. en vez de mandor el valor 100 al registro 3, q fuera al reves, y se lie  :D

¿Como lo has averiguado?, ¿algún debugger en particular?. Yo es que juraría que tengo todos los accesos al PSG centralizados en ROUT, miraré más a fondo a ver.

¡Gracias por el chivatazo!  ;)

Bueno, yo tengo la rutina de sonido aparte, muy sencilla, y andaba mirando los registros una y otra vez, y estaban todos bien. Pero resulta que el fallo no estaba en los datos sino en un cacho de la rutina que le faltaba un inc (hl)  ;D  Por lo tanto hacia eso, leer como registro lo que en realidad era un dato. La verdad no se ni como es que sonaba :-[

Y al final lo he visto volviendo a repasar la rutina. Como hacia dias que no lo tocaba, no me acordaba como narices iba y repasaba instruccion por instruccion, y he visto que algo no me cuadraba y efectivamente era ese inc(hl) desaparecido.

Como debugger uso el del NO$MSX. Tienes el debug normal que te muestra la ram (en hex y asm) y los registros del Z80, pero luego dentro de el en otra opcion esta el I/O Map, que te muestra todos los registros del VDP (msx1 y msx2), del psg, de los puertos del disco, el PIO, el RTC, el memory mapper, las interrupciones.... Fantastico si sabes para que son todos :) yo con los del vdp (y ahora a base de ostias el psg), y poco mas ya tengo :D

Probaré el NO$MSX a ver que tal va....