Karoshi MSX Community

Muy buenas,

Lo primero de todo me presento como nuevo usuario,
Trabajo haciendo aplicaciones para móviles, los lenguajes que domino son Java, C#, JavaScript, C++, etcetc
Recientemente me hice con un MSX1 por pura casualidad. Antiguamente poseia un ZX Spectrum +2b, y movido por la curiosidad y la nostalgia decidí adentrarme en el mundo de la programación retro. Mi pretensión no va mas allá de hacer un juego sencillo pero bien acabado.

El ensamblador utilizado es el asMSX en el EditPlus, tal como viene en el tutorial de zilogZ80

Hasta ahora he avanzado bastante sobretodo gracias a tutoriales como el anteriormente mencionado o el easymbler de Konamiman.
A parte de eso he googleado mucho y estudiado mucho acerca del código maquina, pese a lo cual aun sigo siendo un ignorante y me cuesta picar código de forma fluida. Mi código ahora es una especie de frankenstein hecho a base de pedazos de tutoriales y otros trozos que he ido cogiendo de aquí y allá.

Muchos conceptos del MSX son tratados en los foros como si todo el mundo los conociese y no requiriesen de mayor explicación, pero para un newbie como yo seria de gran ayuda que alguien me ayudase a aclarar algunos de estos conceptos. Tal vez yo tampoco se como buscar para encontrar la información adecuada... En cualquier caso me he decidido a registrarme en este foro y pedir algo de ayuda.

El siguiente video muestra hasta donde he llegado, aunque actualmente ya tengo a los enemigos apareciendo y moviéndose por la pantalla (aunque aun no disparan ni colisionan con los disparos del jugador)
http://www.youtube.com/watch?v=_wI9AUbH5ds (http://www.youtube.com/watch?v=_wI9AUbH5ds)

El código, por si alguien quiere verlo esta aqui:
https://drive.google.com/file/d/0B-6vVXEeG1u3Wk02YXVKZ05wTkE/edit?usp=sharing (https://drive.google.com/file/d/0B-6vVXEeG1u3Wk02YXVKZ05wTkE/edit?usp=sharing)

Bien, las preguntas que quisiera formular son las siguientes:

1) El famoso scroll del MSX. Según he podido leer hay diversas técnicas, pero la única que he llegado a entender es aquella en la que se tiene dos sets de tiles para el escenario, siendo el segundo set el mismo que el primero, pero 4 pixeles subido. De tal modo que alternando entre un set y otro se consigue un efecto mas suave. Esto es así? Aun no he podido probar el programa en la maquina real, no supondrá esta técnica una penalización de velocidad? o el volcado a los bancos de tiles a la VRAM son lo suficientemente rápidos para llevar a cabo esta técnica?

2) Como he dicho en la anterior pregunta, aun no he podido probrar el programa en el ordenador real. Esto es porque el cartucho MegaFlash SCC+ es muy caro y aun no me he decidido a comprarlo. Ello me ha llevado a preguntarme si no es posible meter el juego en otros formatos que no sean rom, pero aunque he buscado mucho, no he encontrado ningún sitio que indique como compilar para disquete o cassete. Como se hace?

3) Según me ha parecido entender, no se puede tener tiles con el atributo de tamaño normal mezclados con tiles con el atributo de tamaño doble, a no ser que se haga algún truco con las interrupciones. Esto es así?

4) El tema de las interrupciones. Es algo que he leído muchas veces pero no llego a entender el concepto de un modo claro.
El siguiente ejemplo expuesto, es posible con las interrupciones?
    a) Pongo los tiles en la mitad de la pantalla arriba
    b) Pongo 32 sprites en la primera mitad de arriba de la pantalla
    c) Interrupción
    d) Pongo los tiles en la mitad de la pantalla abajo
    e) Pongo 32 sprites en la parte inferior de la pantalla
    f) Como resultado se ven 64 sprites en la pantalla, superando el limite por hardware de 32 sprites al mismo tiempo
Es esta suposición correcta? En caso afirmativo, alguien puede ponerme un pequeño ejemplo? En caso negativo, alguien podría explicarme lo de las interrupciones de tal modo que hasta un niño de 5 años entendiera? Hay manera de superar la limitacion de 4 sprites por linea con esta técnica?

5) El tema de la música. He visto algunas librerías para reproducir música. Me gustaría entender como funciona mas o menos.
Según me ha parecido entender, la forma mas básica de reproducir música seria con un array de sonidos pasándolos por una función que va leyendo los datos dinamicamente y durante toda la ejecución del programa, para ir emitiendo los sonidos uno a uno y en orden cronológico. Esto es correcto?

6) Guardado de datos. Es posible guardar records? Como se hace? Es posible hacerlo independientemente de si el programa se compila como .cas, .dsk o .rom?

Muchas dudas de las que tengo las he buscado previamente sin éxito. Sin embargo puede que algunas de las cosas que pregunto sean temas muy trillados anteriormente. En tal caso espero sepan perdonarme.

Gracias de antemano

Asumo que hablas de MSX1, ya que MSX2 o superior tienen "scroll" (sí, entrecomillado) por hardware.

Hay muchas formas de hacer el scroll en MSX1 y dependen, en gran medida, de qué quieres mover, en qué screen y en qué dirección. Lo que tú comentas sirve para hacer un scroll vertical de 4 pixels en 4 pixels, en lugar de un scroll carácter a carácter (que sería de 8 en 8).

El volcado a VRAM será más rápido cuanto menos tengas que volcar. Pero podría darte para volcar prácticamente toda la pantalla.

<publi>Si quieres ver esta técnica llevada al extremo (scroll pixel a pixel), échale un vistazo a mi juego QBIQS :) </publi>


La ventaja del formato ROM es que todo es mucho más natural. Si tu ROM no tiene más de 48K lineales puedes cargarla a través de disquete con el excelentísimo programa ODO.


Si cambias "tile" por "sprite", sí, es así.


No en MSX1, ya que el VDP no puede generar interrupciones que no sean de vblank. La única forma sería sacrificar dos sprites y ponerlos superpuestos a mitad de pantalla. Entonces se tendría que hacer un bucle que estuviera comprobando el bit de colisión de sprites y, en el momento en el que se detecte la colisión, cambiar la tabla de atributos de sprites. De esa forma tendrías unos 30 sprites para la parte superior y 32 para la inferior: 62 sprites.

Y ojo, el volcado a VRAM es lo más crítico, porque es lo que más tarda y lo más dependiente de si el VDP está pintando o no. Lo ideal es realizar este volcado durante el vblank (que es el tiempo entre que salta la interrupción de vblank, al pintar la última línea visible de pantalla, y se comienza el dibujado de la primera línea del siguiente frame). A ese tiempo le tienes que descontar lo que emplee la BIOS si es que la utilizas, claro está.

Por lo tanto, lo ideal es volcar TODO a VRAM en ese tiempo. Ten en cuenta que te va a dar escasamente para actualizar los tiles de toda la pantalla, por lo que lo primordial es el diseño: tener muy claro qué hay que actualizar y sólo actualizar eso.


Cuando se termina de pintar la última línea visible, y antes de pintar la primera línea con el color de borde de la parte inferior, el VDP genera una interrupción llamada vblank. Si el procesamiento de las interrupciones está activado, en ese momento se produce un salto a una dirección de memoria que va a depender del modo de interrupción en el que el Z80 esté en ese momento. Lo normal es que esté en modo IM1, así que se salta a #0038.

Esa rutina se ejecuta, por tanto, cada vez que se termina de dibujar la pantalla: unas 50 veces por segundo en PAL y 60 en NTSC. Es la forma básica de controlar el tiempo en MSX y sincronizar las acciones pertinentes. Cuando se termina la rutina de interrupción, se vuelve al punto donde se había interrumpido (jejeje) la ejecución, la cual sigue.

A grandes rasgos eso es una interrupción. El VDP de los MSX2 y superiores pueden generar otros tipos de interrupción. Otros cacharros pueden generar otro tipo de interrupciones. TODAS ELLAS van a provocar un salto a la misma dirección (#0038 en modo IM1), por lo que si tuvieras que tratar varios tipos de interrupciones, la rutina de #0038 debe comprobar cuál se ha producido. Eso lo hace bastante bien la BIOS, que proporciona unos ganchos en la parte superior de la RAM donde puedes poner un salto a tu rutina de tratamiento de interrupciones.


No sin parpadeos.


Lo primero es saber qué chip quieres usar. Para cada chip hay diferentes programas que permiten hacer música y/o efectos de sonido. Luego sería utilizar el reproductor adecuado, incluir en el código el fichero de música (en el formato que te grabe el programa) y seguir las instrucciones de uso del reproductor.

Por ejemplo, el vortex tracker graba un fichero .pt3, tú lo metes en el código como un binario y el reproductor que hay para asMSX tiene una serie de rutinas que te permiten inicializar la música y luego generar los valores que hay que volcar en los registros de sonido. Yo lo que hago normalmente es seguir este patrón:

esperar interrupción vblank
volcar datos a VRAM (siempre lo más crítico)
volcar datos a registros de sonido
leer mandos
calcular cambios en la visualización para el siguiente frame
generar datos de sonido para el siguiente frame
esperar interrupción vblank...


Siempre es posible, pero depende de dónde lo quieras guardar:

• ¿En la propia ROM? Necesitas que sea FLASH y hacer las rutinas de guardado.
• ¿En el cassete? Pues necesitas las rutinas de lectura y grabación de/al cassette.
• ¿En el disco? Tres cuartos de lo mismo, aparte de tener que meterte con el S.O.

Como ves tus preguntas suscitan más preguntas, pero sigue así :D

Como programador original del asMSX te hago solo una sugerencia fácil para probar tus juegos en el ordenador real.

- Crea el fichero como una ROM (directiva .ROM) en la página 2, es decir, a partir de 8000h (.page 2)
- Añade la directiva para generar un fichero de audio de salida (directiva .WAV)

Ahora, al ensamblar, además del fichero ROM te producirá un fichero WAV de audio. Reprodúcelo desde el PC, el móvil, el MP3 o lo que tengas y conéctalo al MSX real utilizando el cable de cassette, utilizando la instrucción de carga BLOAD"CAS:",R

Así podrás cargar los juegos gratis, aunque con dos importantes limitaciones:

- Solo te valdrá en principio para ROMs de hasta 16 KB
- La velocidad de carga es la más rápida entre las estándar, es decir, 2.400 baudios

Si en lugar de usar la directiva ROM usas las directiva BASIC, te generará un BIN en lugar de un ROM. Ese BIN lo puedes cargar en el MSX desde BASIC empleando BLOAD. Si lo copias en un disco, podrás cargarlo directamente. Si no, puedes cargar el WAV de audio directamente por el puerto de cassette, y te aguantará así hasta 32 KB (teóricamente).

Y si quieres generar ficheros para cargar desde disco en MSX-DOS, utiliza la directiva .dos o .msxdos, no recuerdo bien. Comprueba las instrucciones para ver qué te cuentan.

Bienvenido al foro y al MSX, y muchos ánimos para seguir adelante con tus proyectos.

Hola!

Si es tu primer juego para MSX yo te recomendaría "aparcar" las técnicas avanzadas (scroll suave, screensplit para tener más sprites, etc.) e intentar alinear el juego a las limitaciones del MSX.

Unos comentarios al respecto del código:

Por lo que veo haces scroll sacando una línea de la tabla de nombres de VRAM a RAM y volviendo a volcar una línea más arriba... y todo con la BIOS. Entiendo que el mapa es cíclico de 24 caracteres de alto. Dado que ya tienes los valores a volcar en ROM (GFX_STG_1_MAPS_1 y siguientes), creo que sería mucho más eficiente hacer lo siguiente:

• Estoy en el frame x, calculo u=x módulo 24 y v=24-u
• A partir de origen GFX_STG_1_MAPS_1 + 24*v y destino NAMTBL, hago un bucle de u volcados LDIRVM de una línea (24 caracteres) y voy actualizando el destino (avanzando líneas)
• A partir de origen GFX_STG_1_MAPS_1 y con el destino que tuviera, hago un bucle de v volcados LDIRVM de una línea (24 caracteres)
• Incremento u

Y además te valdría para el volcado inicial.
Bueno, estoy viendo ahora que tienes 18 líneas de patrones, no 24... habría que ajustar un poco el algoritmo, pero creo que la idea es buena.

Por otra parte, veo que utilizas Pletter-VRAM... Quizá te salga a cuenta pasarte a Pletter-RAM con un buffer. El volcado de gráficos puntuales será algo más lento (habrá que hacer luego un LDIRVM), pero puedes descomprimir una vez y volcar a los tres patrones y además te valdría para los datos: diseño de niveles, enemigos, etc.

Por las extensiones de los ficheros me imagino que usas PCX2MSX. Como veo datos de tablas de nombres en el código, imagino que las habrás hecho a mano. Échale un vistazo a este hilo (http://karoshi.auic.es/index.php/topic,2472.0.html), que a lo mejor te doy una alegría </autobombo> :P

Por lo demás, aunque hay cosillas que pulir, ¡yo creo que vas francamente bien!

Hi Mr Matsusaka,
Very nice start! Welcome !
I've mailed you something that answer some of your questions
AR

Bienvenido y tal :D

Te digo lo mismo que Nestruo. Ahora para empezar olvídate de cosas raras y no te compliques. Hazlo sencillo y céntrate en un buen diseño y en que sea divertido. El MSX tiene sus limitaciones y tal. No te calientes ahora en superarlas, simplemente ves aprendiendo, cógele el gustillo, descubre cosas y pásatelo bien con ello.

Los adornos floridos técnicos no valen UNA MIERDA (así escrito en plata) si el juego es aburrido y soso. Lo cual no quita que puedas hacer mil pruebas de mil cosas, ¡es parte de la diversión! :) Pero no te ofusques.

Ah, y no te fies jamás de los emuladores, son el diablo ;) Muy bien para probar y debuggear, pero que jamás te eviten probar el código a fondo en la máquina real, que luego hay sorpresas y nada funciona como debe. En este sentido, las Megaflash no son caras. La cantidad de jugo que les sacas valen cada euro invertido.

Hola!

Me sumo a lo dicho por mis compañeros.
En lo que puedas utiliza la BIOS donde tienes mucho trabajo hecho y te garantiza compatibilidad entre ordenadores/generaciones.

Sobre el tema música te puedo hablar del WYZplayer desarrollado por un compañero de estos foros (Iggy Rock). La música y los FX se puede desarrollar desde su cross-tracker WYZtracker (para win), y exportar para asMSX (aunque adaptable para otros compiladores). Permite tener varias canciones aprovechando un único set de instrumentos y esta optimizado para ocupar poca memoria pensando en el desarrollo de juegos. Tendrás que bajarte el player y adjuntarlo a tu proyecto. Parta hacerlo funcionar, lo primero es iniciar el player indicando que canción quieres hacer sonar. Luego desde la interrupción llamar la rutina que reproduce el buffer de sonido y en el hilo principal del juego la función que interpreta las pistas de la canción (casi todos los players funcionan igual). En cualquier momento puedes lanzar un FX del juego pero solo uno a la vez.
https://sites.google.com/site/wyzplayer/
https://sites.google.com/site/augustoruiz/

Lo que se muestra en el vídeo tiene muy buena pinta!! :o
para ser una "ópera prima" tiene mucho nivel, sobre todo los gráficos.  ;)

participas en la msxdev'14?

Animo con tu proyecto!

Muchas gracias por vuestras contestaciones y perdonad la tardanza en contestar.

SapphiRe:
Si, hablo de MSX1.

Esta buenísimo! No solo lo suave del scroll, tambien lo original de concepto. Una especie de mezcla del tetris con un juego de naves!
Hablando del scroll, creo que de momento, y como dice theNestruo, voy a dejarlo asi de momento para no complicarme demasiado la vida. En cualquier caso si al final lo intento se que camino tomar. Gracias!

Creo que me ha quedado bastante claro el tema de las interrupciones, al menos a nivel teórico. A parte de esta explicación he leído mas explicaciones tuyas en otros temas como este.

http://karoshi.auic.es/index.php?topic=1931.0
Esta claro que no había buscado lo suficiente! :P
Pero aun no me queda claro un detalle. En la practica, a nivel de código, como se que parte del código entra dentro del vblank y cual no? Se puede controlar?

Otra cosa. Que hace "halt"? Recuerdo que al principio sin una llamada a este comando la velocidad del juego era excesiva. Al añadirlo la velocidad bajo a unos niveles mas normales. A mi modo de ver lo interprete como una especia de controlador de frames. Busque en internet pero las explicaciones sobre este comando eran bastante técnicas, y difíciles de entender. Me gustaría mas que una explicación de como funciona internamente una explicación de como afecta al juego y que usos prácticos tiene.

Cuando tenga un poco de tiempo voy a invertigar este vortex tracker.

Uf, supongo que al final el juego será en formato rom, así que mirar lo del cassete o el disco seria una perdida de tiempo de momento.
Podrías explicarme un poco el procedimiento para guardar en la propia rom?

Muchas gracias por tus explicaciones.

De momento he comprado por ebay el cable (el reproductor aun tengo que mirarlo un poco mas)
El rom resultante aun no supera los 16 kilobytes, así que supongo que aun puedo hacer la prueba en formato .wav. Igualmente la directiva BASIC puede ser otra solución alternativa.
EDIT: he probado la directiva BASIC y me genera el bin sin problemas, pero la directiva .WAV no me la reconoce, me da error de sintaxis.
EDIT2: creo que al final me voy a comprar el cartucho flash... :P

En cualquier caso muchas gracias y sobre todo agradecerte personalmente que hayas desarrollado asMSX!

Basicamente asi es. Copio la primera fila de tiles de la VRAM a RAM en un buffer que no vuelvo a tocar hasta el final.
Luego para el resto de filas hago el mismo procedimiento con otro buffer pero al volver a volcar a VRAM lo hago una fila mas arriba.
Y al final pego el buffer del primer paso a la ultima fila correspondiente en la VRAM.

Supongo que copiar datos de la VRAM a la RAM no es lo mas optimo no?
Con tu sistema lo único que se pierde es un poco de memoria, por lo que me parece entender.

Teniendo en cuenta que mi scroll esta formado por 16 lineas * 24 tiles eso serian 384 bytes de buffer. Supongo que no es tanto, pero lo cierto es que ya he tenido un par de avisos quedándome sin espacio RAM. Merecerá la pena el ahorro de velocidad? Como no puedo testear el juego en el ordenador de verdad no se hasta que punto las cosas que programo serán lentas :P

Esto me lleva a otra pregunta que me ronda la cabeza últimamente.
Los datos para engendrar nuevos enemigos son estáticos, no los genero dinamicamente, sino que ya están definidos en un largo array de datos. Al meter la información de las tres fases con las que el juego contará me quede sin espacio en la ram. Hay forma de tener toda la información en la rom pero que solo se cargue en la ram la información de la fase correspondiente?

Como veis soy SUPER newbie. :P

Si, uso PCX2MSX. Aunque he montado un .bat que me procesa los graficos de una manera muy comoda para mi proyecto.
Ahora no tengo mucho tiempo asique hechare un vistazo luego a tu link para ver que me puede ofrecer!

Hombre, el concepto es original de Konami, que hizo el Quarth en 1990.


Se pueden hacer pruebas. Yo lo que hago en la fase de pruebas es cambiar el color de fondo cuando entro en la interrupción y después volver a cambiarlo cuando termino de volcar a VRAM (que es, repito, lo más crítico). Así puedes ver una franja de color diferente. Si esa franja llega (por la parte de arriba) a meterse dentro de la imagen (es decir, llega más abajo del borde), entonces es que el código que has ejecutado entre ambos cambios de color tarda más en ejecutarse que el tiempo de vblank.


Realmente halt lo que hace es repetir indefinidamente la instrucción nop. Sólo se detiene ese bucle indefinido si se produce una interrupción (y no están desactivadas). Así que halt lo que hace es... esperar una interrupción. Como, para nuestros propósitos, la única interrupción que se tiene en cuenta es la del vblank, lo que te permite hacer halt es sincronizar el código con el trazado de la pantalla y así asegurarte de que la actualización de pantalla (por ejemplo) se realiza cuando no se está pintando la pantalla y, por lo tanto, no habrá glitches (errores gráficos visibles).

También, como el vblank ocurre cada cierto periodo de tiempo (1/50 seg en PAL, 1/60 seg en NTSC), te permite tener un control del tiempo, para tareas que lo requieran (timer, reproductor de música...)


Para eso el juego debe estar en formato físico y que el cartucho te permita hacer eso. Yo lo olvidaría de momento, no es algo trivial.

Hola Mr Matsusaka, bienvenido, es una alegría ver cómo sigue llegando gente con ganas de aprender. Me ha gustado mucho el vídeo de lo que llevas hecho, ¿Los gráficos también son tuyos?

Todavía no he podido mirar el código, pero hay una cosa que me extraña un poco y es eso que comentas de que el buffer de 384 bytes puede ser mucho porque te estás quedando sin RAM, ¿Con que la estás ocupando? Una vez que tienes todo ya cargado en vram con un puñado de bytes para las variables de posiciones, disparos, marcadores y alguna cosita más deberían ser suficientes. Quizás te podría servir esto que tengo un poco a medias pero que funciona: http://karoshi.auic.es/index.php/topic,2201.0.html sería muy sencillo modificar las rutinas para hacer que el desplazamiento fuera circular con la misma idea que comenta theNeustro.

En cuanto a la velocidad que tendrá en un MSX real, es prácticamente la misma que la que tendrás en el emulador porque en temporización son bastante exactos, pero deberías probar con la BIOS oficial en lugar de con C-BIOS, porque las rutinas de lectura/escritura oficiales a VRAM son muy conservadoras (lentas), y las de C-BIOS son bastante más rápidas. Así que mejor probar con lo peor que luego funcionará bien en todos los casos. Y por lo mismo deberías de probar con una máquina a 60Hz, porque tienes menos ciclos por interrupción para hacer todo o necesario, y luego a 50Hz seguro que irá bien, pero al contrario puede que no.

Saludos

Muchas gracias por tu explicación. Creo que al fin he dado con una explicación .
Las pruebas que dices que cambias el color el fondo cuando entras en la interrupción, a nivel de código seria precisamente tras el halt, no es así?
Creo que voy a probar a insertar este sistema. Muchas gracias!

Una pregunta tonta: si pongo dos halt seguidos, con eso conseguiría que el juego vaya a 25 fps en PAL?

Sobre el guardado, creo que lo vamos a dejar así. Al fin y al cabo solo seria para guardar records.
Los juegos comerciales que guardaban datos, llevaban incorporada una memoria flash para tal efecto, o se hacia de otra manera?

En cualquier caso muchas gracias por todo vuestro apoyo, gracias a la información que aquí he recabado me siento con mas confianza para avanzar en la programación de este juego!

Bueno, en realidad yo era del Spectrum, pero me hice con un MSX de casualidad y una cosa lleva a la otra y...
Los gráficos son míos al 100%. Si alguien quiere que le haga gráficos para algún proyecto estoy abierto a escuchar propuestas.


Principalmente con la información de los enemigos, donde aparecen, en que momento y con que propiedades. Debe haber como 50 enemigos en la primera fase, y mas de 100 en la tercera. Toda la información está en el código, pero de momento he comentado los datos de la segunda y la tercera fase. Si descomento aunque solo sea la segunda, el compilador me dice que no puede acceder a determinadas partes del código. Supongo que esto es un indicativo de que he sobrepasado la memoria de la pagina, no es así?


Si, yo estoy con la C-BIOS. Tengo que probar la BIOS normal como dices.
Muchas gracias por tu mensaje!


Estoy pensando en comprarme el cartucho flash. He visto que hay principalmente dos.

El MegaFlashRom SCC(60 EUROS) y el MegaFlashRom SCC+ SD(99 EUROS el mas barato). La diferencia de precio es considerable, pero supongo que poder meter las roms en una SD será infinitamente mas cómodo que tener que comprar una interface para poder conectar el cartucho al pc, no?

A parte el MegaFlashRom SCC+ tiene versiones con 512 kb de ram extra + otra ranura para una segunda SD. No se si merece la pena desembolsar un poco mas de dinero por estas características. Es útil para algo en concreto tener esta segunda ranura? Los 512 kb de memoria extra seria para ejecutar roms con mas contenido? Teniendo en cuenta que solo funcionaria en ordenadores con similares capacidades, perderíamos compatibilidad si usamos esos 512 kb, no es así? En caso negativo, para que son esos 512 kb?

Coooorrecto. La primera instrucción tras el HALT será la primera que se ejecute tras procesar la interrupción. Como supongo que usarás la BIOS, perderás un poco de tiempo, pero bueno, de momento es lo que hay.


Sí, pero no es buena idea. Lo que puedes hacer es actualizar la pantalla uno cada dos frames y tendrías el mismo resultado. PERO la música sí hay que actualizarla cada frame.


En la época no había flash, así que usarían S-RAM.

Bienvenido a la comunidad y muy buan pinta lo que nos has enseñado!

Y con respecto a lo que debas o no debas hacer, tira de tu propio instinto. Yo he hecho cosas sencillas y arriesgadas, y de todas sacas siempre lo positivo del aprendizaje: aunque yo también te recomiendo que utilices BIOS al principio para transferencias a VRAM, lectura de sticks, etc... ya tendrás tiempo de ir haciendo las cosas más hardcore (ojo, que en mi caso casi siempre tiro aún de BIOS para casi todo).

Un saludo y al hierro!!

No sé si existe dicha interface, yo que lo que hago para manejar el MegaFlashRom SCC es grabar el contenido que quiero meterle junto con el programa de comunicación (opfx.com) y los archivos de MSXDOS en un diskette de 720kb desde el PC (sí, mi PC tiene diskettera, me aseguré de ello al renovarlo), y luego cargar el contenido usando dicho programa de comunicación desde un MSX2.

Por otra parte, creo que ahora mismo solo están disponibles las versiones SD.

Hola!

Gracias a vuestros consejos he avanzado un poco mas en la demo. Ahora tiene musica y enemigos (aunque muy primitivos)
Mirando otros foros he visto lo del megarom. Ahora creo que voy a poder meter todo el contenido que tenia pensado desde el principio!

http://www.youtube.com/watch?v=-TR_ShKubtw

Bienvenido Mr Matsusaka!!

He visto el video y me he quedado muy gratamente sorprendido. Aqui hay usuarios con un muy buen nivel de programación y estaras en tu salsa.

Yo lo que si te puedo recomendar tambien encarecidamente que te hagas con la megaflash con SD . Sera infinitamente mas comodo para tí. Te olvidas de cintas,discos,wavs para los restos... Eso si con la de una ranura para la Micro Sd tienes mas que suficiente. La de los 512 KB no si si en MSX1 te puede servir para para ejecutar ROMS de mas tamaño.

Aqui un hilo del portal MRC donde podras resolver tus dudas al respecto.

http://www.msx.org/node/41958 (http://www.msx.org/node/41958)

Saludos y animos!

Siento llegar tan tarde al hilo.

Me encanta que con mis tutoriales te hayas animado a entrar a formar parte del grupo que se lanza a programar un juego en ensamblador.

El juego tiene una pinta muy buena, y se nota que ya has programado otros juegos en plataformas mas actuales.

Espero ver terminado tu proyecto y presentado a ser posible en esta edición de la MSXDEV14.

Un saludo.

Gracias por tu bienvenida mesiasmsx. Me temo que el cartucho lo tendré que comprar tarde o temprano. Habrá que ahorrar un poquito.

zilogZ80a, a ti te debo que me haya metido en esto, pues no recuerdo haber visto un tutorial de este tipo de computadoras antiguas tan bien explicado y directo. Es una pena que no lo continuases, se echa en falta algun capitulillo que explique los controles o el sonido en profundidad.

No se si me dará tiempo al MSXDEV14. Cuando es?

Buenas,
Vengo con unas preguntas mas.

Estoy a punto de implementar las balas enemigas.
El caso es que estoy pensando en añadir una colisión de sprites en medio de la pantalla para así poder reescribir la tabla de atributos de sprites y poder tener los 62 pixeles en pantalla en lugar de los 32 habituales.

Como el juego es de scroll vertical, no me queda mas remedio que crear un par de buffers para rellenarlos con atributos todos los frames con todos los sprites que necesite pintar. Cuando un elemento vaya a estar en la parte alta de la pantalla, lo incluiré en el buffer 1, y en el otro caso lo haré en el buffer 2.

Al final del ciclo volcaré los atributos del primer buffer en la VRAM, chequeo de la colisión, y volcado del segundo buffer.
Es esta aproximación correcta?

Por otra parte, he estado buscando tutoriales para detectar las colisiones de sprites, pero solo he encontrado código en BASIC o cosas que me cuesta mucho entenderlas. Alguien podría tener la amabilidad de explicarlo de tal modo que hasta un niño de 5 años entendería?

Por cierto, esta técnica no se vería arruinada si se producen otras colisiones de sprites anteriores a la que vamos a forzar en la mitad de la pantalla?

Gracias de antemano.

PD: Me compre el SDD+, y es una gozada verlo en el MSX autentico!

Mira este tutorial, a ver que te parece.
http://web.archive.org/web/20131008220425/http://infinitemsx.com/index.php?option=com_content&view=article&id=27:collision-detection&catid=16:blog&Itemid=7

Por cierto, la pagina de infinite esta caida o desaparecida.  ::)

If I correctly understand, you are on the right way for screen split but there is a detail to make clear (sorry maybe it is only a problem of my comprehension of Spanish)
You need in VRAM two SATS, one for the upper half of the screen another for the lower part.
You can swap the two SATS by writing vdp register #5
E.g.  
set Vdp R#5 = 0x36  ;   SAT at 0x1b00 for upper sprites
set Vdp R#5 = 0x37  ;   SAT at 0x1b80 for lower sprites

To swap at a given raster line I suggest you poll not for collisions but for 5th sprite condition.
Just sacrifice the last 5 sprites from the upper SAT and set them transparent at Y = 128 (out of the active area of your game, eg. X = 255)
This means that the VDP will report in the status register 5th sprite condition for plane #31 (the last one)

At ISR the raster beam is at the very beginning of the lower border, so you can do something like this:

ISR:
set Vdp R#5 = 0x36  
do other stuff (eg. VRAM update for PNT and sprites, music ecc..): NB make sure this code always ends BEFORE the raster line is at Y = 128, or you will miss the split line

poll the status register and test for bit 6 (meaning 5th sprite condition) and for plane 31 (in the lower 5 bits)

1:  in  a,(0x99)
    and 0x5f
    cp  0x5F        ; plane 31 =0x1F
    jp  nz,1b

You need this to avoid other 5th sprite conditions that can happen in the upper part of the screen. If they happen, they will involve lower sprite planes, so you can skip them, as this polling loop will wait exactly for plane 31 being the 5th sprite on a line.

set Vdp R#5 = 0x37  (SAT at 0x1b80 for lower sprites)

do other things (if needed )
ret

I hope this helps
 ;)

About how to fill the two sats, you are on the right way: objects that need to appear in the upper half of the screen have to stay only in the first sat, objects that need to appear in the lower part of the screen have to stay only in the second sat

BUT

when an object moves across Y = 128 you have to put it in both SATs or it will partially disappear during the transition

Hi Arturo!

Your answer is really apreciated. I also have a piece of code about this thread you sent me some weeks ago.
To be honest, I don't feel like I have the level to be able to implement this easily, not to mention to understand the code.
Anyway, if sometime in the near future I feel with strenght to go for it now I know where to look.

A couple of days after I posted my last message I decided to implement the second possibility you recomended me by mail, the flikering SAT reversal.
This technic is not as impresive than the other one, but definetely it's easier for me, and I have already implemeted on the code.

Thanks anyway for all your kindness!

Por cierto, tengo una nueva demo con todos los avances hasta ahora

https://www.youtube.com/watch?v=PFHiyc_5Xrk (https://www.youtube.com/watch?v=PFHiyc_5Xrk)

Hi, AR. We had this discussion in 2006. I think the 5th SPRITE rule is not 100% MSX compatible: there some issues with some MSX1 (with 9928 and 9929).

Sorry, I've forgotten our discussion (8 years ago...)
What was the issue ?

We, in this forum, without you.

If I remember well, not all the MSX1 will detect the 5th sprite. It works in every MSX2 or superior but not in all the MSX1. The 5th sprite detection didn't need to be implemented in all the MSX1. The were problems with this detection in MSX1 with the 9928 and 9929.

as the status register is well documented in official tms notes and all the above chips formally share the same specs are you telling that there are buggy chips in some msx machines ?

It seems to work on the TMS 9918 but it's buggy on the TMS 9928 and TMS 9929.

And, don't forget, that not all MSX1 have a TMS. For example, the SONY HB-10P has a Toshiba T6950 instead; so you can't do things like mix mode here.

T6950 does support the status register with the 5th bit flag and the indication of its plane (tested on the real thing).
Status register and support of undocumented modes have nothing to do each others, why do you mix them ?

Apart that, even if IMHO certain kind of discussions are totally dull, the fact that some 9928 are buggy does not make a fully documented feature out of the msx standard (9918/28/29 share the same TMS manual and specs).

This topic has been talked several times through the years. I can't find all the post about that; do the research if you want to. In one of them it was pointed out what I told you before about the 9928 and 9929.

Also, there is a user who spotted a MSX1 which didn't check the 5th sprite flag properly. It's not so a strange computer but a SONY HB20: Page 6 of this (http://karoshi.auic.es/index.php/topic,1281.75.html) thread. There, it was said what I have already told you, that the flag which detects the fifth sprite was not compulsory in the beginning for the MSX1 computers so some brands, like SONY, used another VDP instead of the TMS; detecting the 5th sprite is not a "must" for the computer for being a MSX1. Having at least 8K RAM, a Z80, 1 or 2 Joysticks, etc ... is compulsory; the 5th sprite flag, not.

In the last comment I said -adding some more information to this topic- that there are more issues with some MSX1 computers, like the (in)famous mix mode. I am not mixing anything here.


If discussing a topic about MSX compatibility / programming, in which I am VERY MUCH interested, is a "totally dull conversation" for you, what are you doing in this forum?

so nothing t do with T6950


In order to say that this or that feature is not part of msx standard, you should point an official document that tells a certain thing is not mandatory or not included.
Hardly I believe you will be able to find such exception in official documents, that will point to official TMS manuals for the description of the vdp HW, which in turn describe the status register with 5th sprite flag and the rest.

If you find it, chapeau!, if not, what you just are telling is that there are some buggy machines from the very early series of msx that can could have a glitches with this feature. Nothing to do with compliance to the msx standard.

Do you know why the z80 has undocumented instruction ? Because the very early series of that chip were buggy and did not support properly 8 bit operations on IX/IY registers, so Zilog decided to not include in official documents the buggy instructions, that have been fixed in later productions.
Would you say that games that use undocumented instructions for z80 are out of msx standard? Never the less, msx standard includes z80 only for its "official" part, and in theory, there could be some early machine mounting one of first versions of the buggy z80 chip...


Sorry, IMHO you are mixing msx standard definition with what you think should be the good practices to not incur in problems with some machines. It's a personal view,  respectable but I wouldn't claim that it is the msx standard. And naturally, in 2014, I have another view.
Using only msx bios and only mainstream features you wouldn't have had a large part of the homebrew products or a single demo. But this, as any religion war, is a dull discussion.

TMS is no official document for MSX at all. The ASCII Technical Handbook (http://www.konamiman.com/msx/msx2th/th-1.txt) is the official one: read the standards there.


That a MSX machine doesn't have a feature like the 5th sprite flag and another one (most of them) does have that feature doesn't mean that the first machines are buggy. Your code is buggy, since it doesn't work in all machines which are 100% compliance with the MSX standard ASCII established.


Again, those early MSX machines are not buggy. If you know that some features were improved in later MSX machines and you code only for them, you are creating something which doesn't work in all MSX machines, obviously, you are coding something not 100% MSX compliance.


My first message to you was: "Hi, AR. We had this discussion in 2006. I think the 5th SPRITE rule is not 100% MSX compatible: there some issues with some MSX1 (with 9928 and 9929)."

I wanted to bring some light/new perspective, since this topic has been very deep discussed here in the past years. Maybe what some users said was not properly proved and you did. I have some games myself which use the mix mode (my code is buggy in some MSX1 machines since I am ignoring those MSX1 which are 100% ASCII MSX compliance but doesn't have that later feature) and if the 5th sprite works on most MSX machines, I will use that instead of the synchrocode I am using now for a little slpitscreen. Obviously, you decided to take the conversation to a non productive field.

You are mixing topics here: standard (that was my only interest: a "it doesn't work in all machines but in most of them" would have been great) vs MSX practices. You are putting words in my mouth I didn't say: "you are mixing msx standard definition with what you think should be the good practices". I tell you, you are completly wrong. I don't think coding following only the standard should be the good practice. You said that; I never did.

As I said, asking a technical question about programming/hardware, in a MSX forum, in the development thead, is not a "totally dull conversation". Something you already said twice.

You can end your messages with "Sorry, IMHO (in my humble opinion)" but you are still being unpolite.

dioniso, sorry if i'm direct, but this kind of discussions return too frequently
let's stay on the msx standard: ascii documents say "TMS9918 or equivalent"
maybe I'm missing something: where do you find exceptions on the 5th sprite flag ?

If there is no exceptions in official documents, machines with buggy chips are just buggy machines
If you avoid that feature to make your code work even on those machines, it is remarkable, but I'd never say that it is to comply the msx standard.

In the Technical Handbook it's said TMS9918. In the TMS9918A, which is an improved version of the TMS9918, the 5th sprite flag is already listed. I just can't find the datasheet of that first TMS9918 (TMS9918A with less features).

Related topic: I have just had a look at another ASCII book, the MSX Technical Data Book English version, 1984. And in page number 10, under MSX hardware specifications, where the MSX standard is, it is said"CPU Z80 compatible (...) 1 WAIT in M1 CYCLE", which would leave undocumented instructions with the registers IX and IY out of the standard, since they take 2 cycles in M1.

Back to topic. If we ignore these last messages and go back to what I wanted to know: did you (you and friends) test this feature in several (many?) MSX1 computers. As I said, I would like to implement this if it works on most (not necessarily all) of the MSX1 machines.

Please, TMS9918 does not have screen 2 support.  It was introduced with TMS9918A.
It is the main difference between TI-99/4 and TI-99/4A. The latter has TMS9918A which support screen 2, the former has TMS9918, without screen 2.
Look here http://shawweb.myzen.co.uk/stephen/artic6.htm (Screen 2 in the TI world is called "bitmap mode" )

Would you tell that screen 2 games are not msx standard ?
I think that taking too literally that ascii document about msx2 does not lead very far.
Same issue about z80 undocumented opcodes, I would keep using them despite the 2 M1 cycles  ;-)

I think that, if a conclusion can be drawn, we should be less manicheist in telling what can be done and what cannot be done  because out of the msx standard (and again, I feel stupid in touching this topic here and now - in 2014, after about 30  years of the death of the msx standard).

About the status register and the 5th sprite flag, I can help you only about the tests I did on my Panasonic turbo R and on a philips 8020 from a friend. The split screen polling the 5th sprite flag was working as expected.


[edit]
Anyway coding screen 1 games has its appeal as you can swap freely between a number of tilesets loaded in vram. Even with  screen 1 color limits it is possible to have decent results.

Dioniso
Just a contribution

http://www.msx.org/forum/development/msx-development/msx1-vdp-statusregister-details

Do you know what does not work properly on status register of 9928/29 ?  Is it bit 6 or the bits 0-4 ?

Normally, reading the status register during the tracing of the active area returns the last sprite plane processed if the 5th sprite flag is 0, or the last 5th sprite plane found if the 5th sprite flag is set.

Ideally you could not poll bit 6 at all, before swapping the two SATs.
You only need to know how many sprite planes are used in the upper part on the screen and wait to read that value in bits 0-4 of the status register.
In any case, you will miss the right split point if by chance you get with 5 sprites on the same line somewhere in the upper part of the screen, as the plane counter will stop, reporting the last 5th sprite plane.

Said that, for managing tons of bullets on the screen, a quick an safe way is to accept some controlled flickering and go for sprite reversal.

If you want up to 64 sprite on the screen, create a SAT with 64 entries in RAM and copy it to VRAM on Vblank from the top in odd frames and from the bottom in even frames.

If you have less that 64 valid entries in the SAT in RAM, you could arrange things in order to have flickering only for bullets (just place them at the beginning and at the end of the virtual SAT).

E.g. you can have
- bullets in plane 0-15,
- enemies in planes 16-31,
- bullets in planes, 32-47
Enemies will not flicker while the 32 bullets will appear in alternate frames

This allows also to have more than 4 sprites per line.

AR, we are two MSX users who think the same about what a game/demo should be. About the standards, it seems what ASCII themselves said is quite incongruent.

My only point was to see if most of the MSX have the 5th sprite flag and it seems so. I know of some users who will never use that; I respect their opinions, too.

I don't have much time now; I have to read your last two messages slowlier and deeply. I have just read you can have more than 4 sprites horizontally. That's something I will investigate in your messages and links. When I did some test (about a year ago) with synchro-code in IM2 I tried to show 4 sprites on the left and then change the SAT to place the same ones (or lower/higher planes) just to the right ... and the first one on the left just disappeared. I thought it was not possible to place more than 4 hardware sprites in a row. As I said, I will see that again after having read your messages.

Clearly not a compatibility issue rather anything ranging from hw bug to not reliable verification of the issue.
TMS clones support 5th sprites and even TMS doc say about this.

In the ascii docs there is TMS or EQUIVALENT but equivalent means that is functionally interchangeable by definition so if TMS support 5th an equivalent of TMS MUST ALSO support 5th flag

Conclusion: your discussion is a non-sense. Instead an ipotetic TMS like chip that does not have 5th flag feature IS NOT standard by definition.

And another one ...

update:
I've just tested: there is no need of 5 sprites on the same line to do a clean screen split.

It is sufficient to place one single sprite on a known plane as placeholder, say plane 31, and poll the last 5 bits of the status register.
This latter keeps counting the processed sprites, and even if it shows the last plane where the 5th sprite condition has happen, it is sufficient to read it twice to get the actual number of processed sprites.

In the end, willing to use two sats, you can show up to 31+32 sprites at the same time
If you place your placeholder on plane 31, in the ISR routine you have to poll for that value in the last 5 bits of status register before swapping the sats.




The sacrifice of the last sprite from the upper SAT is worth of extra 32 sprites.

x Dioniso
I'm pretty sure that all the chatting about status registers and 5th sprite detection is due to a well know fact: if you read the status register while its flags are being set you will miss the flag bits. It is normal and documented and due to the fact reading the status register resets the flags.
But if you read the last 5 bits twice or more (as my polling code does) you cannot incur in the above problem.
If you find a tms9928 I'll send you a test rom.

[edit]
Obviously, telling out of the msx standard something that seems not working, isn't, let me be polite, a good idea (read it as an attempt to not start another dull flame war on religious subjects).



 

I'll try this new approach. Yesterday in the night I couldn't [edit] quite get it to work. Somehow I was missing the flag being set.

So I'll set the last sprite (plane) at y=60, do some things, and before the raster is at that y=60 I'll do a loop to "freeze" until the bits 0-4 have that sprite plane. I'll tell you later or the next days.

halt
;do some stuff

last_plane:
in a,($99)
and 31
cp 31 ;it doesn't have to be the 31st plane, it could be cero, for instance.
jp nz,last_plane

;splitscreen

I'll try that to achieve the same I do here (https://www.youtube.com/watch?v=7IHfQEAWa8M) with synchro-code, with SCREEN 2 on the higher and lower parts of the screen and SCREEN 3 in the middle. The quality of the video is not good; the scroll part is supossed to be soft.

I guess I'm missing something. With the 5th sprite flag or the sprite plane polls I just get into an infinite loop ... I'll see that again tomorrow night and try to make it work.

Sorry this demo does not shows what it should
https://sites.google.com/site/devmsx/split-screen-on-msx1/split%20screen.rar?attredirects=0&d=1

Tomorrow I'll try more using real hw an I will tell more
In my previous experiment I discovered I was actually having 5 sprites even if I wasn't testing the 5th bit flag

The demo shows the normal split screen using 5th bit flag: you can see two SAT's with 64 sprites active

https://sites.google.com/site/devmsx/split-screen-on-msx1/split%20screen.rar?attredirects=0&d=1

this is why on emulators it does not work without 5 sprites on one line
http://www.msx.org/forum/development/msx-development/msx1-vdp-statusregister-details?page=3
tomorrow I'll try on real HW

Interesting due to the fact that it can be used for knowing whether you are using a real machine or not. So, it could be easy way for real cartridges in order to avoid emulators.

Am I mistook?

Correct, but the rom posted works on emulators too as the polling loop tests also the 5th sprite flag
if you want to do a test that works only on real HW you need to poll for &h1F skipping the flag

[edit]
I updated the files in the attach
https://sites.google.com/site/devmsx/split-screen-on-msx1/split%20screen.rar?attredirects=0&d=1

Now the files in the "standard" directory show a normal split screen using 5 sprites on a line as split point.
The code works in emulators and shows two sat's of 32 sprites (total 64) on the same screen.
The last 5 sprites of the upper sat have to be sacrificed as placeholders for line split

The files in "active sprite counter" directory show a screen split using just one sprite as split point
The code does not work properly on emulators and I have to test it (I hope tonight) on real HW
The last sprite of the upper sat is sacrificed as placeholders for line split so you can use 63 sprites freely
After the tests on real HW I'll tell if it works as expected.
 

I've just tested files in "standard" directory and those in "active sprite counter" directory on my TR and only the split screen that uses the 5th sprite flag works.

In order to reproduce hap's results on the behaviour of "sprite counter" of the status register more tests and investigations are needed.

Anyway, Dioniso, if you can, try the standard files. The split screen works great and I expect nothing strange on msx1 vdp's.

I have also tried both ROM in a MSX1 HB-75D. The "sprite counter" one doesn't work properly and everytime I reset de MSX I have a different result; showing 8 sprites at the top and none or 32 at the bottom. Could it be the way of writing to the VRAM?

I could reproduce the SCREEN 2- SCREEN 3 - SCREEN 2 screen splits I coded with syncho code using your technique of the 5th sprite flag but not with the "active sprite counter". Thanks for the code. If you want to do some tests on the HB-75D (Germany, PAL) just tell me. I also have some others MSX1 computers:

-SONY HB-75P (Europe)
-SONY HB-75 (Japan)
-SONY HB-55 (Japan)
-PHILIPS VG8020 (Europe)
-Alamiah AX-150 (Arabic)
-DAEWOO ZEMMIX CPC-51B (Korean console)
-MSX Selector-6 (Japanish console for hotels with 6 slots for cartridges)

You can send me a mail and I can take photos or videos of the ROM running in a MSX1.

Thanks! Actually I'm starting to think that hap's ideas about the status register working as "active sprite counter" is just a mental trip :-)

I did some more tests on my TR without success: if the feature exists and turns out to be only present in TMS9918 (and equivalents) but not supported by V9938/58, it could be not worth of being emulated and used in actual SW.

I'll try to do a test rom where the position of the placeholder can be changed by keyboard.
In this way it should be possible to pass from "standard" screen split with 5th sprite condition to "active sprite counter". I let you know asap.

Hola!

Después de mucho tiempo vuelvo por estos lares con una nueva pregunta.
Anteriormente pregunte por la interrupciones para dibujar mas de 32 sprites. El caso es que en mi juego es difícil controlar los sprites que habrán en la parte alta de la pantalla y los que habrán abajo. Bien podria ser que los 64 esten el la parte alta o baja en determinados momentos.

Así que renuncie a esta idea y me decidí por otra idea que me dio AR, que es la de hacer parpadear los primeros 32 frames y los últimos entre frames pares e impares. Aunque no se vean perfectamente no es un mal sistema. Ademas puestos los sprites con inteligencia el sistema también sirve para evitar el problema del 5º sprite.

Ahora la pregunta es esta: veo que cuando 5 sprites se sobreponen en la misma linea la acción se ralentiza, siendo esto cada vez mas patente si la superposición de sprites sucede varias veces al mismo tiempo. No parece conveniente, ya que ralentiza la acción en determinados puntos. Esto supongo que se trata de la famosa interrupción. Probablemente la respuesta sea negativa pero, existe manera de desactivar esta interrupción del 5º sprite?

Gracias de antemano