Anoche probé este ejemplo en casa y suena muy guay!
Lo que comentabas de la tabla de asignación de tono y ruido a los 3 canales no viene en el libro que yo tengo. Te suena de algún sítio por internet que venga eso??

A ver si pruebo esta noche el ejemplo de WYZ!

Si utilizaras ese valor en ensamblador directamente correrías el riesgo de fundir el PSG. Afortunadamente, el BASIC es bondadoso y pongas el valor que pongas en el registro 7, siempre hace primero OR &h80. Esto es así porque los dos bits de más peso tienen que ser 1 y 0 respectivamente, indicando el "flujo" del PSG. De usar valores diferentes, podría reventar todo. De hecho, a eso se refería Patriek Lesparre cuando decía en el fallo de MSXdev'05 lo de "dangerous writes to reg #7".

Cuidadín con esos puertos.

Encontré la tabla:

       RUIDO                        TONO
  C       B       A             C       B       A
  32     16      8             4       2       1

Sumas los valores y luego:

SOUND 7, 63-suma.

Lo que comentaba antes: el intérprete de BASIC ya comprueba eso y añade por defecto ese 80h al escribir al registro 7 del PSG. Si usas el comando SOUND no puedes freír nada en el MSX.

Lo que sí haría sería penalizar por la operacion 128+63-valor. Podríamos usar 191-valor, por ejemplo.

De todos modos, ¿cómo nos estamos liando tanto con una cosa así? Es mejor optimizar mini-rutinitas en ensamblador, para ver si hay pique sano y todos nos ahorramos algún byte o algún ciclo. ¿Alguien propone alguna?

Supongo que bromeas, pero eso es un tema puntilloso... igual que penalizar ciertas cosas que se han penalizado y no creo que sea justo. Y lo digo porque el MSXDev es un concurso de juegos, no un concurso de programación pulcra... vamos, que las tripas del juego deberían dar igual a la hora de valorarlo. La valoración del juego no debería ir más allá de gráficos, música, jugabilidad y originalidad.

Vamos... es mi opinión...

Además, en mi caso (ya que utilizo NestorPreter) como puedo definir constantes, al operar con ellas se proporciona claridad, pero una vez generado el programa basic quedan como lo que había escrito SapphiRe.

Un ejemplo tonto:

Si declaro:
@DIR_BASE 100

Y luego hago:
X=@DIR_BASE+100

En el programa basic quedará así:
X=100+100

Volviendo al topic del audio :


Échale un vistazo a este enlace del "MSX Technical Handbook" :

http://www.konamiman.com/msx/th-5a.txt

Aquí vas a encontrar información muy interesante acerca del funcionamiento del PSG.

Y si lo quieres completo (que no sólo de PSG vive el MSXero), Robsy te lo ofrece gentilmente en su página :

http://www.robsy.net/msxtech.pdf



Estaría genial que, teniendo en cuenta las limitaciones del pobre PSG, se recopilara una colección de snippets de sonido con la simulación de instrumentos o de efectos como el de sirenas, explosiones, clicks, ping y pongs. En fin, algo rápido de usar para el que no tiene ni idea de como hacer el ruido del motor de un cohete para su juego, por ejemplo.


Espero que no haya sido dentro de la taza...


¡Por Dios!, ¡¡que no haya sido dentro de la taza!! 

Pero has entendido el por qué?

Me estaba refiriendo al MSXDev, más que al concurso de BASIC... pero vamos... que da igual, ya que el criterio debería ser el mismo. Creo que temas como lo del R#7 del PSG no deberían haberse penalizado porque, para empezar, el código del replayer no era ni siquiera propio de cada programador. Si, por poner un ejemplo, en un futuro se pudiesen presentar juegos hechos en NestorBasic, yo hago un juego y luego resulta que el Nestorbasic tiene un error... debería penalizarse mi juego??

Evidentemente, si pruebas el juego en cinco modelos distintos de MSX y en cuatro no va... eso es otro tema...

Con todo ésto quiero decir que para ser juez del concurso ni siquiera se debería saber programar... sino saber de juegos y de MSX. Y a poder ser, no debería haber un sólo juez... yo incluso me inclino más por votación popular (aunque eso tiene el peligro del amiguismo... pero ya somos mayorcitos).