Reglas del Concurso MSX-BASIC 2015

Logo Concurso MSX-BASIC 2015

Condiciones

  • La participación en el concurso está abierta a cualquier persona o grupo.
  • No hay límite en el número de entradas a presentar.
  • Solo participarán en el concurso juegos: de aventura, plataformas, RPG, puzzle, arcade, etc. Otro tipo de programa será descalificado.
  • Los juegos presentados tienen que ser inéditos. Los plagios o copias de otros ya existentes bien en su totalidad o en parte (música, gráficos, rutinas, etc.) serán descalificados.
  • Se recomienda incluir información sobre el juego (que no será calificada para concurso), por ejemplo: comentarios del código, imágenes, historia, etc.
  • Los juegos se enviarán acompañados del código fuente original en un archivo de texto.
  • Una vez enviado el juego, las posibles versiones posteriores que se presenten no entrarán en el concurso. Por ello se recomienda a los participantes cerciorarse de que envían la versión definitiva.
  • La presentación de las entradas a concurso se realizará a través del formulario que aparece al final de este texto. No se aceptará ninguna entrada enviada por otro medio.
  • Hay que tener en cuenta que el formulario tiene restringido el tamaño de archivos adjuntos a 5MB (5242880 bytes).
  • Una vez recibidos los datos del formulario, el autor recibirá un email de confirmación.
  • Cualquier duda o pregunta de índole general se responderá en los comentarios que acompañan a esta entrada del Blog. De esta manera la respuesta a la duda de uno puede ser la respuesta para otro.
  • De manera excepcional y si la consulta tuviera carácter privado existe la posibilidad de enviar un email a concursomsxbasic@msxblog.es.

Categorías

El concurso se divide en dos categorías bien diferenciadas:

  • Categoría A – Juegos en MSX-BASIC: los juegos presentados en esta categoría usarán código MSX-BASIC puro y no podrán usar ninguna instrucción ampliada (llamadas CALL). Sí se permitirá para casos concretos invocar una rutina de código máquina muy específica pero que haya sido definida mediante instrucciones MSX-BASIC (POKE, etc.) (ver detalles más abajo).
  • Categoría B – Juegos que hagan uso de NestorBASIC o MSX-Basic Kun: En este caso se podrán usar los comandos CALL que sean inherentes a la herramienta utilizada (CALL TURBO ON, etc.). El uso de rutinas en código máquina estará sometido a las mismas restricciones que la categoría A («MSX-BASIC») y que se definirán más adelante.

Ambas categorías serán juzgadas de manera individual dada la notable diferencia de rendimiento y características posibles entre las dos; funcionará, por tanto, como si fuesen dos concursos en paralelo.

Plazos

  • El plazo de presentación de entradas a concurso termina el 14 de enero de 2015 a las 23:59:59 horas (horario de Canarias) . Las entradas presentadas fuera de plazo serán publicadas (si así lo desea su autor) pero no entrarán a concurso. Para evitar posibles problemas en la entrega se recomienda no dejarlo todo para el último día.
  • El 1 de febrero de 2015 se abre el plazo de valoración de las entradas por parte del jurado, que finalizará el 28 de febrero de 2015.

Uso del MSX-BASIC

Existirán una serie de restricciones y normas que deben respetarse en ambas categorías y que se definen a continuación:

  • Se permite el uso de MSX-BASIC en sus versiones para MSX de primera generación y MSX2, quedando excluido el MSX-BASIC usado en MSX2+ y MSX turbo R (en este también queda excluido por supuesto el uso del procesador R800)
  • Los juegos tienen que estar programados completamente en MSX-BASIC, no estando permitido el uso de lenguaje ensamblador en general, ni de ningún compilador de BASIC u otro lenguaje; se considera una excepción a esta regla el uso de la herramienta NestorBASIC o MSX BASIC Kun para las entradas de la categoría B.
  • Se permitirá solamente una rutina en ensamblador, que ha de ser idéntica para todos los participantes. Dicha rutina, cuya longitud es de 12 bytes, será la siguiente:
LD HL,ORIGEN	; Origen en RAM
LD DE,DESTINO	; Destino en VRAM
LD BC,LONGITUD	; Longitud del bloque a copiar
JP LDIRVM		; Salto a la rutina de copia
  • Con esta rutina se pueden cargar gráficos en VRAM de una manera más rápida. La forma de cargar esta rutina en memoria será a través de POKEs, para ser posteriormente llamada mediante el uso de las instrucciones DEFUSR y USR. Podrá localizarse en cualquier parte de la RAM accesible desde BASIC y se podrán cambiar los valores de los tres parámetros tantas veces como sea necesario.
  • El juego podrá ser presentado en formato .CAS, .ROM o .DSK.
  • El juego puede estar compuesto por uno o varios bloques grabados con las instrucciones SAVE”CAS:”” o BSAVE””CAS:””. Se permite que el juego pueda realizar cargas desde cinta, abriéndose, por tanto, la oportunidad de presentar juegos multicarga.
  • Si el juego lo requiere, podrá solicitar al jugador que rebobine la cinta.
  • En caso de presentarse en formato DSK, se permite la carga de datos y gráficos desde disco. Para ello se pueden usar las instrucciones LOAD y BLOAD. Opcionalmente el juego podrá grabar datos en disco (utilizando BSAVE) para guardar datos que puedan ser recuperados en otra ejecución del juego (tales como records, progreso, etc.). El uso arbitrario del disco para la creación de juegos puede penalizarse de la manera que se detalla en el apartado Jurado (ver más abajo).
  • En el caso de bloques binarios, éstos solamente podrán contener datos, debiendo ser cargados con la instrucción BLOAD”CAS:”” (sin autoejecución).
  • En el caso de bloques con código en BASIC, cada listado debe cumplir todas y cada una de las restricciones que se listan a continuación, sin excepción:
  1. Prohibido el uso de la instrucción CALL.
  2. DEFUSR y USR: Se pueden definir llamadas a la rutina en ensamblador anteriormente citada, así como a aquellas rutinas de BIOS que no requieran el paso específico de parámetros (p.e. CHGET, DISSCR, ENASCR, etc.).
  3. OUT: Por compatibilidad sólo se permitirán instrucciones OUT a las direcciones del PSG y del VDP, si se accede a este último mediante OUT se deberá garantizar una total compatibilidad con el estándar (leyendo los valores adecuados de la BIOS con la instrucción PEEK).
  4. POKE: Se puede usar en cualquier dirección de la memoria desde el final del programa hasta &HFFFE, es decir, no se permite modificar el programa con POKE (prohibido código automodificable). La dirección &HFFFF no deberá ser escrita al tratarse del registro de selección de slots expandidos.
  5. Se permite el uso de las instrucciones LOAD (con y sin autoejecución) y RUN para la carga de bloques de programa en BASIC, tanto desde CAS como desde DSK. La carga de bloques de datos se realizará única y exclusivamente con la instrucción BLOAD (sin autoejecución), desde disco podrá utilizarse el parámetro S para cargar datos directamente a VRAM. Si se desea se podrán incluir los nombres de los ficheros a ser cargados.
  6. Prohibidas las instrucciones relacionadas con la impresora.
  7. Prohibidas las instrucciones añadidas por alguna extensión al MSX-BASIC (cartuchos con ampliaciones, etc.) excepto las mencionadas de MSX-Disk BASIC.
  • No hay limitación en el número de líneas a usar.

Jurado

  • El jurado estará formado por todos los participantes en el concurso.
  • Es obligatorio que cada uno de los participantes valore al resto de entradas de su categoría. En caso contrario todas sus entradas en dicha categoría serán descalificadas.
  • El fallo del jurado es inapelable.
  • Se valorarán los juegos conforme al siguiente criterio:
    • El miembro del jurado valorará por separado cuatro aspectos del juego (entre 1 y 95), a saber: jugabilidad, originalidad, gráficos y sonido. Se calcula la nota media.
    • Hay 5 puntos de bonificación que el miembro del jurado repartirá como desee entre los cuatro aspectos mencionados en párrafo anterior. A la nota media calculada anteriormente se le suma el valor más alto de bonificación otorgado (que será de 5 puntos máximo si van todos a la misma característica y de 2 puntos mínimo si se reparten entre las cuatro características a valorar). El número obtenido será la nota final del miembro del jurado para ese juego que llamaremos resultado parcial.
    • Se repite la operación descrita en los párrafos anteriores con cada uno de los miembros del jurado y finalmente se calcula la nota media de los resultados parciales que será la nota final.
    • Es obligatorio que cada uno de los miembros del jurado otorgue los puntos de bonificación y justifique con un comentario breve su aplicación en cada aspecto concreto. En caso contrario, el miembro del jurado será descalificado del concurso y sus entradas quedan excluídas.
  • Los juegos que hagan uso de la carga de datos desde disco serán valorados de una manera diferente. Si el jurado considera que el uso del disco es arbitrario y no imprescindible entonces el juego perderá TODOS los puntos de bonificación. En tal caso, el jurado tiene que hacerlo constar expresamente en los comentarios de su valoración.

Premios

En cada categoría del concurso se premiará al juego con mejor puntuación general y al juego más original.

En caso de que en cualquiera de las dos categorías del concurso participe solamente un juego, la organización se reserva la opción de entregar  únicamente un premio.

Los premios para ambas categorías consistirá en una exclusiva placa conmemorativa.

Ayudas a los participantes

Gracias a la ayuda de SapphiRe (por la programación) y a la posterior de TheNestruo (por la modificación), está a disposición de los participantes un listado MSX-BASIC con el que se puede cargar la rutina en ensamblador descrita en el epígrafe Uso del MSX-BASIC.

10 DEFFNUB(N) = (((N AND &HFF00)6) AND 255)
20 DEFFNLB(N) = (N AND 255)
30 SCREEN 1
40 RO=&HC000
50 VD=&H1800
60 NB=&H300
70 AD=&HBFF0
80 GOSUB 100
90 END
100 POKE AD,1:POKE AD+1,FNLB(NB):POKE AD+2,FNUB(NB)
110 POKE AD+3,17:POKE AD+4,FNLB(VD):POKE AD+5,FNUB(VD)
120 POKE AD+6,33:POKE AD+7,FNLB(RO):POKE AD+8,FNUB(RO)
130 POKE AD+9,195:POKE AD+10,92:POKE AD+11,0
140 DEFUSR=AD:AD=USR(0):RETURN

Explicación del código:

  • Las líneas 10 y 20 definen dos funciones para obtener el byte alto (Upper Byte) y el bajo (Lower Byte) de una dirección de 16 bits.
  • En la línea 30 ponemos SCREEN 1
  • La línea 40 define el origen en RAM de los gráficos a volcar (Ram Origin).
  • La línea 50 define el destino en VRAM de los gráficos a volcar (Vram Destination).
  • La línea 60 define el número de bytes a copiar (Number of Bytes).
  • La línea 70 define la posición de memoria donde queremos que se ejecute la rutina (siempre que esté libre, cualquiera).
  • La línea 80 llama al cargador de la rutina.
  • La línea 90 termina el programa.
  • La línea 100 carga el número de bytes.
  • La línea 110 carga el destino.
  • La línea 120 carga el origen.
  • La línea 130 carga la llamada a la BIOS.
  • La línea 140 crea el defusr, llama con usr y vuelve.

El resultado es que se vuelcan 768 bytes en la tabla de nombres de la VRAM, es decir, toda la pantalla de SCREEN 1.

También YMN ha querido colaborar con la siguiente explicación:

Además de lo anterior, la solución de codificación de la rutina assembler es implementar una aplicación de producción adaptable, o sea, un programa que hace programas.

La aplicación solicita los mismo datos que el listado que aparece más arriba y genera el código fuente del cargador, implementado para ser llamado con GOSUB.

Para procesar el código generado:

  • Posicionar el cursor en la línea 10 y pulsar 2 veces RETURN.
  • Teclear GOSUB 10 + RETURN.
1 DEFFNT(N)=(-(N0)):DEFFNH(N)=INT(FNT(N)/256):DEFFNH$(N)=HEX$(FNH(N)):DEFFNL$(N)=HEX$(FNT(N)-FNH(N)*256)
2 DEFFNS$(A$)=STRING$(2-LEN(A$),”0″)+A$:DEFFNX(N)=VAL(“&H”+HEX$(N))
3 INPUT “DIRECCION DATOS ORIGEN EN RAM: “;RO:RO=FNX(RO)
4 INPUT “DIRECCION DATOS DESTINO EN VRAM: “;VD:VD=FNX(VD)
5 INPUT “NUMERO DE BYTES A COPIAR: “;NB:NB=FNX(NB)
6 INPUT “DIRECCION RAM DEL CARGADOR ASSEMBLER: “;AD:AD=FNX(AD)
7 PRINT “10 FOR I=&H”+HEX$(AD)+” TO &H”+HEX$(AD+11)+”:READ A$:POKE I,VAL(“+CHR$(34)+”&H”+CHR$(34)+”+A$):NEXT:DEFUSR=&H”+HEX$(AD)+”:RETURN”
8 PRINT “20 DATA 21,”+FNS$(FNL$(RO))+”,”+FNS$(FNH$(RO))+”,11,”+FNS$(FNL$(VD))+”,”+FNS$(FNH(VD));
9 PRINT “,01,”+FNS$(FNL$(NB))+”,”+FNS$(FNH$(NB))+”,C3,5C,00″

Explicación del código:

  • Líneas 1-2: Define funciones para obtener el byte alto y bajo en formato alfanumérico, establece el valor hexadecimal con dos dígitos y obtiene el valor de un número en formato decimal complementado.
  • Líneas 3-6: Define en formato complementado el origen en RAM de los gráficos a volcar (Ram Origin), el destino en VRAM de los gráficos a volcar (Vram Destination), el número de bytes a copiar (Number of Bytes), y la posición de memoria donde queremos que se ejecute la rutina.
  • Líneas 7-9: Genera el código fuente del cargador de la rutina, para ser llamado con GOSUB.

Agradecimientos

A todos los participantes en las diferentes ediciones del concurso por su esfuerzo y colaboración en la divulgación del MSX-BASIC a través de sus juegos.

A SapphiRe, theNestruo y YMN por compartir sus conocimientos y elaborar las rutinas de ayuda.

A José Ángel Morente por su apoyo técnico en la nueva redacción de las reglas del concurso para la edición 2015.

Formulario

IMPORTANTE: El formulario que aparece a continuación es el único medio habilitado para enviar vuestros juegos a concurso, no se aceptará ninguna entrada enviada a través de otro medio.

[contact-form-7 404 "Not Found"]

18 Respuestas

  1. Jorge Romero dice:

    Pregunto, que yo aun soy muy torpe para estas cosas y tengo ganas de hacer algo para el concurso:

    La rutina en ensamblador entiendo que es para pasar datos de ram a vram. ¿Tenéis por ahí algún ejemplo de juego o programa que la utilice? Es para ver ejemplos de como se le puede sacar partido.

    Si yo hago un juego para MSX2 ¿puedo usar funciones de MSX Basic 2.0 o se cuenta como ampliación del Basic?

    Espero que este año mole aun mas que el del año pasado, que había cositas muy muy chulas. 😀

    Por cierto, ¿desde cuando lleva haciéndose el concurso?

    • Konamito dice:

      Hola Jorge.

      En primer lugar me alegro de que tengas ganas de participar en el concurso. Ánimo.

      En segundo lugar, voy a contestar a tus dudas:

      No soy programador pero creo que igual echándole un vistazo al código fuente de los juegos puedes ver cómo están hechos e igual te sacan de dudas. Si no, puedes esperar a que alguien con los conocimientos y la experiencia adecuada te conteste por aquí.

      En cuanto a tu segunda duda, puedes hacer un juego para MSX, MSX2, MSX2+ o MSX turbo R.

      Saludos.

      • theNestruo dice:

        Hola Jorge!

        Si quieres, échale un vistazo al código de Pérez the Mouse.
        El código está dividido en dos; la preparación (POKE) de las rutinas está en un cargador aparte y el uso está en el propio juego (de cuyo código subí una versión ampliamente comentada en HTML).
        En mi caso se utilizaba para: cargar los patrones y colores (que es lo ideal porque ahorras un montón de memoria y además los cargas de forma casi instantánea) y también para cargar las diferentes pantallas.
        Y si quieres que te eche una mano con el tema mándame un correo 🙂 (está en el readme del juego)

        Un saludo,
        Nés.

  2. Konamito dice:

    Corregida la fecha límite de entrega: 31 de diciembre de 2014 y añadido el formulario.

  3. Kotai dice:

    Veo que se continua sin dejar usar el compilador x-basic… Yo, una vez he conocido el compilador ya no le veo sentido hacer juegos en BASIC puros ya que son muy lentos y el compilador sin cambiar ni una línea de código BASIC (solo la llamada a TURBO ON) permite que tu juego tenga una velocidad «jugable»

    • Konamito dice:

      Entiendo tu queja, Kotai. La lentitud del BASIC es un lastre en muchas ocasiones para hacer juegos. Sin embargo, yo lo veo desde el punto de vista del romanticismo del lenguaje de programación puro: limitado pero capaz de hacer cosas muy divertidas.

      Saludos.

      • Silver dice:

        Hola Konamito.

        En primer lugar felicidades por tan magnífico blog.

        Respecto a las normas coincido con Kotai. Creo que el uso del compilador abre la puerta a mas creatividad y seguimos respetando la filosofía Basic…y perder un referente como Kotai en el concurso es una pena. Es como usar ensamblador en las rutinas… es solo una opinion mas.

        Y me repito!! Enhorabuena Konamito por tu gran trabajo para los amantes MSX, excelente.

        • Konamito dice:

          Antes de tomar una decisión al respecto, voy a consultarlo y a pensarlo bien…

          • Javi dice:

            ¿Y por que no se permite programarlo en Java, pero con un aspecto y estructura parecida al msxbasic?. O mejor todavia, se podria programar solo para emuladores, donde puedes acelerar la velocidad de emulacion, con lo que irian mas rapido.

            Yo soy mas de la opinion de Konamito «el punto de vista del romanticismo del lenguaje de programacion»

          • Silver dice:

            Bueno Javi, creo que este razonamiento esta alejado del debate…Un compilador respeta el romanticismo del lenguaje, tan solo evitamos el paso intermedio del intérprete y se aplica a un Msx real en su originalidad. Emulación, java, no era esta la discusión planteada…

          • Kotai dice:

            Por la respuesta que das, creo que no sabes como funciona el compilador X-BASIC. Este compilador era un cartucho (aunque también se puede hacer cargando un fichero binario con BLOAD) que simplificando mucho lo que hace es añadir 2 nuevos comandos más al BASIC, las instrucciones TURBOON y TURBOOFF. Tu sigues programando en BASIC de toda la vida, pero cunado llamas a la instrucción TURBOON se compilan de golpe las líneas entre esa instrucción y la TURBOOFF haciendo que ese bloque de código se ejecute más rápidamente. A cambio pierdes unos 12KB de RAM que se come el compilador. Por lo tanto la programación sigue siendo 100% el BASIC de toda la vida y compatible en todos los MSX, pero cambias unos 12KB de memoria por más velocidad a la hora de ejecutar el programa.
            Sin compilador te las ha de ingeniar para obtener una velocidad decente mientras que con compilador te las has de ingeniar con la poca RAM disponible, pero los juegos ganan mucho en velocidad y por lo tanto en jugabilidad.

          • Konamito dice:

            Bueno, para cerrar el debate de «BASIC compilado sí, BASIC compilado no» he decidido modificar las reglas del concurso y hacer dos categorías separadas y bien diferenciadas. Por un lado, juegos TURBO, aquellos que utilizan MSX-BASIC compilado. Y por el otro, juegos MSX-BASIC estándar. La diferencia entre los juegos de ambas categorías será más que notable debido a la velocidad de ejecución. Por ello es necesario que compitan en categorías diferentes porque la velocidad de los juegos penalizará muchísimo a los que no hagan uso de BASIC compilado.

            En unas horas o a más tardar mañana lo haré oficial.

            Gracias por vuestra colaboración.

          • Javi dice:

            Kotai, tengo una idea de como funciona el compilador y para mi no es algo del estandar. En mi MSX no funcionaria el juego porque no tengo el cartucho. Si es cuestión de poner cartuchos, etc. para que funcione, ya hay extensiones del basic para ampliar los comandos, etc.

            Esto es solo mi opinión y cada uno tiene la suya, aunque como siempre es Konamito el que tiene la ultima palabra.

  4. Konamito dice:

    ACTUALIZADAS LAS REGLAS

    Gracias a todos por las sugerencias…

  5. Konamito dice:

    ¿Cómo llevan las entradas? Queremos saber más cosas sobre los juegos que se están cocinando en vuestros MSX…

  1. 21/09/2014

    […] por el retraso en publicar las modificaciones de las Reglas de nuestro Concurso MSX-BASIC 2015 que había anunciado. Pensaba tenerlas listas antes pero José Ángel Morente y yo hemos estado repasando el texto […]

Deja tu comentario sobre esto

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

A %d blogueros les gusta esto: