Aspectos generales
- Puede participar cualquiera que lo desee.
- Solamente se puede presentar un juego por participante.
- Solamente se aceptarán aquellos programas que sean videojuegos, valiendo cualquier género: aventura, plataformas, RPG, puzzle, arcade, etc.
- Los juegos presentados tienen que ser originales. No se permiten plagios ni copias de otros ya existentes en su totalidad o en parte (música, gráficos, rutinas, etc.). Los juegos que incumplan esta regla quedarán automáticamente descalificados.
- Si el autor lo desea, podrá incluir información extra sobre el juego: comentarios del código, imágenes, historia del juego, etc. Estos contenidos no serán calificados.
- Los juegos se enviarán a webmaster@konamito.comproporcionando los siguientes datos:
- Nombre del juego.
- Nombre o nick del autor.
- Email de contacto.
- Para evitar posibles extravíos del email, se ruega a los participantes, si no han recibido respuesta en dos o tres días, que vuelvan a enviarlo.
Plazos
- Las entradas se pueden presentar desde hoy, y hasta el 31 de diciembre de 2011 a las 23:59:59 horas (horario de Canarias) . Una vez finalizado el plazo de entrega no se admitirá ninguna entrada.
- Antes del 15 de febrero de 2012 la organización debe haber recibido las valoraciones correspondientes a cada uno de los juegos de los participantes en el concurso. En caso de un participante no entregue sus valoraciones sobre el resto de los juegos , será descalificado (ver apartado Jurado, más abajo).
Uso del MSX-BASIC
- Los juegos tienen que estar programados completamente en MSX-BASIC, no estando permitido el uso de lenguaje ensamblador en general, MSX-BASIC compilado, etc. Sólo se permite una única rutina en ensamblador, idéntica para todos los participantes. Dicha rutina, cuya longitud es de 12 bytes, será la siguiente:
LD HL,ORIGEN ; Origen en RAMLD DE,DESTINO ; Destino en VRAMLD BC,LONGITUD ; Longitud del bloque a copiarJP 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 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 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:
-
- Prohibido el uso de la instrucción CALL.
- DEFUSR: Se pueden definir llamadas a rutinas en código máquina de la BIOS y a la rutina en ensamblador anteriormente mencionada.
- 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).
- POKE: Se puede usar en cualquier dirección e la memoria desde el final del programa hasta &HFFFF, es decir, no se permite modificar el programa con POKE (prohibido código automodificable).
- USR: Se podrán realizar llamadas a rutinas en código máquina previamente definidas con DEFUSR respetando las restricciones para dicha instrucción. El paso de parámetros, tanto de salida como de entrada, sí está permitido, siempre que sea a través de la instrucción USR.
- Se permite el uso de las instrucciones LOAD”CAS:” (con y sin autoejecución) y RUN”CAS:” para la carga de bloques de programa en BASIC. La carga de bloques de datos se realizará única y exclusivamente con la instrucción BLOAD”CAS:” (sin autoejecución). Si se desea se podrán incluir los nombres de los ficheros a ser cargados.
- Prohibidas las instrucciones relacionadas con la impresora.
- Prohibidas las instrucciones añadidas por alguna extensión al MSX-BASIC (como las de DiskROM, cartuchos con ampliaciones, etc.).
- Cada listado MSX-BASIC puede tener el número de líneas que se desee, numerándose siempre de 10 en 10.
- El juego se entregará en formato .CAS y además se acompañará de los listados correspondientes en tantos archivos de texto como sean necesarios.
Jurado
- El jurado estará formado por todos los participantes en el concurso.
- Cada participante tendrá que valorar al resto de entradas a concurso. En caso contrario quedará descalificado automáticamente.
- El fallo del jurado es inapelable.
- Se valorarán los juegos conforme al siguiente criterio:
- Se valorarán separadamente cuatro aspectos, puntuándose entre 1 y 95: jugabilidad, originalidad, gráficos y sonido.
- La nota final emitida por cada participante para cada uno de los juegos se calculará realizando media de los puntos otorgados a: jugabilidad, originalidad, gráficos y sonido.
- Hay 5 puntos de bonificación que se repartirán entre jugabilidad, originalidad, gráficos y sonido, pudiendo ir los 5 puntos a un solo aspecto.
- Es obligatorio otorgar estos puntos de bonificación así como explicar su aplicación con un comentario breve.
- La nota final de cada juego será la resultante de calcular la media de cada una de las notas medias de los jueces.
Premios
- Un juego MSX y una camiseta.
- Una camiseta.
- Un llavero, chapa o pin.
Patrocinio
El concurso está abierto al patrocinio de todo aquel que lo desee. Para ello es necesario que se ponga en contacto previamente con la organización: webmaster@konamito.com.
Ayudas extra
Como ayuda incluyo aquí el listado MSX-BASIC con el que se puede cargar la rutina en ensamblador descrita en el apartado Uso del MSX-BASIC. La rutina ha sido programada y testeada por SapphiRe a quien le agradezco su trabajo.
Actualización: Modificadas las líneas 10 y 20 a sugerencia de theNestruo10 DEFFNUB(N)=(N \ 256)-(SGN(N)=-1)*25620 DEFFNLB(N)=N MOD 25610 DEFFNUB(N) = (((N AND &HFF00)\256) 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 nuestro amigo 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.
Por fin, las reglas,
me ha gustado mucho la inclusión del trozito de código máquina, ahora en vez de hacer “for/vpoke/next” para cargar gráficos vamos a hacer “for/poke/next” que es más rápido.
me parece un poco absurdo.
Como punto positivo, creo que es interesante la inclusión de bloques BSAVE””,S ¿supongo?
De cualquier manera, empezaré a pensar mi entrada
Hombre Job’s
Puedes hacer el bucle o cargar los graficos con bload en ram y luego ejecutar la rutina en asm ¿no?
yo no lo veo tan absurdo…
me rectifico, llevas razón cybernoid, habia dado por hecho que se admitian los juegos en .dsk por lo que no veía claro el uso de la rutina cuando se puede usar bload””,s.
Despues de releer las normas me he dado cuenta que solo se admite formato .cas
no sé, no me convence mucho …
yo también me he llevado una pequeña decepción con las reglas.
Pero bueno, es lo que hay, hubiese preferido la posibilidad de usar DiskBasic a ese “pedacito” de código maquina.
Me uno también al desconcierto… creo que están curradas y demuestran empeño, cuando menos. Pero sigo sin entender, por ejemplo, qué mal hace usar BLOAD””,s, o el acceso a disco. No tengo ni idea de cómo se hace eso de cargar la rutina ASM con poke’s, al menos se podría dar resuelto ese punto ya que viene impuesto: directamente un código básic que copie todo (tiles, sprites, colores) a la VRAM, como hacemos con BSAVE/BLOAD, y que todos usemos el mismo… Aun así me parece liar la madeja innecesariamente, porque nadie va a coger estos juegos y cargalos en cinta…
Un saludo a todos.
Cargar la rutina con pokes es tan sencillo como cargar los siguientes 12 bytes (en decimal):
33,L,H,17,E,D,1,C,B,195,92,0
y llamar a la dirección donde se hayan cargado. Los valores de H,L,D,E,B y C son:
H=origen DIV 256
L=origen MOD 256
D=destino DIV 256
E=destino MOD 256
B=longitud DIV 256
C=longitud MOD 256
Según las reglas, la rutina puede ser llamada tantas veces como se quiera y los valores de origen, destino y longitud modificados a voluntad. Es lo más genérico para que cualquiera pueda adaptarlo a las necesidades específicas de cada juego.
Lo he agregado a la retroagenda: http://retroinvaders.com/es/cal:45:konamito-concurso-msx-basic-2011
Konamito esta permitida cualquier generación de MSX?
Si, cybernoid. El juego puede ser para cualquier generación MSX. Eso sí, todos participan juntos, no hay categorías…
Bien, después de observar la normativa del contest comentar lo siguiente:
Se puede apreciar en la normativa la inclusión de algunas de las opiniones y sugerencias que se publicaron en su momento, como la rutina assembler, etc.
Aunque la normativa es correcta de forma general, existen puntos en relación a los jueces que deberían ser rectificados de forma inmediata:
Si en su momento el organizador expuso que “¿Creéis que es fácil encontrar a gente dispuesta a dar de su tiempo para examinar con lupa los juegos?”, pués lo ha solucionado remitiendo la responsabilidad a los participantes.
El problema de esto, son los posibles efectos sobre el resultado, las posibilidades son:
– Efecto Eurovisión. Suficiente que un grupo se organice, para provocar un trato de favores.
– Dispersión de resultados. Es posible, que la intención de algún participante sea perjudicar a otro participante, con premeditación y alevosía, por algún motivo fuera del contest.
Se deben de aplicar medidas para evitar este tipo de prácticas fraudulentas.
Para evitar la dispersión de resultados, las posibles soluciones son:
– Anular las valoraciones que presenten un excesivo distanciamiento con la media.
– Se debe aplicar otro tipo de estadístico para la nota final emitida por cada participante para cada uno de los juegos, por ejemplo la moda.
En este sentido, cada participante evalua la jugabilidad, originalidad, gráficos y sonido para cada uno de los juegos.
La organización evalua la moda de estos apartados, y realiza la media.
Por otro lado, no existe el derecho de anonimato así como de no valorar, posiblemente para dar transparencia a las valoraciones, pero esto presenta otra serie de problemas:
– Agravio comparativo entre participantes y aplicaciones, con repercusiones de tipo social.
– Valoraciones inadecuadas de los participantes, para evitar conflictos.
El participante puede solucionar esto, valorando todas las participaciones con la misma puntuación, evitando toda responsabilidad.
En cuanto a los comentarios sobre las preferencias en el uso de DiskBasic, para cargar pantallas gráficas, la adaptación es muy fácil y evita la restricción de la unidad de disco.
En relación a los premios, no se puede entender que el tercero no tenga camiseta.
YMN si un grupo de usuarios se organiza para conseguir un juego de MSX y una camiseta es que hasta yo se la pago xDDDD
Konamito, ¿podrías publicar un código basic que implemente la rutina en ensamblador de las bases del concurso, a modo de ejemplo?
Bien, no se trata de que “un grupo de usuarios se organize para conseguir un juego de MSX”, sino la posibilidad de tergiversar resultados que se alejen de una valoración equitativa.
Por otro lado, el hecho que expresa la expresión de “hasta yo se la pago”, se puede aplicar observando las bases de la normativa.
En relación al ejemplo solicitado, @Tomi sería interesante tu email de contacto, se adjunta el siguiente código que adapta un archivo gráfico de disco:
– El archivo GFX se copia en CAS:
BLOAD “GFX.SCR”,&H9000
BSAVE “CAS:GFX”,&H9000,&H9000+16*1024
– Se implementa el loader:
10 BLOAD”CAS:”
20 FOR I=&HD000 TO &HD00B:READ A$:POKE I,VAL(“&H”+A$):NEXT
30 DEFUSR=&HD000:A=USR(0)
40 GOTO 40
50 DATA 21,00,90,11,00,00,01,00,40,C3,5C,00
YMN creo que te lo tomas todo muy en serio 😛 esperemos que esos desalmados no haga acto de presencia en el concurso. jejej 😉
Tal y como manifiesto en esta entrada del blog, el concurso queda suspendido por los motivos expuestos en la misma.
Gracias de todas maneras por vuestro apoyo.
Konamito, ¿vas a reabrir el concurso?
He estado meditando al respecto y la respuesta es sí. Estoy preparando una entrada para comentar el rumbo que tomaré respecto a Konamito.com en adelante.
Pero desde ya podéis considerar activo nuevamente el Concurso MSX-BASIC 2011.
Konamito: no me queda claro si el concurso sigue vigente o lo has cancelado, lo pregunto para actualizar la agenda de RetroInvaders
Hmmm mmmm pensando que hacer en Basic…hmmm. 😉
Actualizadas las reglas con código MSX-BASIC para cargar la rutina en ensamblador.
Se agradece la ayuda con el código de la rutina en ensamblador, ahora sólo falta probarlo… 🙂
A ver si se instaura la moda de preestrenos, demos y anuncios de futuras entradas al concurso, como en otras convocatorias. Un saludo a todos!
Bien, además del extra publicado, 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 extra de las bases del contest 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,
establecer el valor hexadecimal con dos dígitos y
obtener 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),
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.
Muchas gracias YMN por tu ayuda. Voy a añadir tu comentario al texto de la entrada.
Saludos.