Karoshi MSX Community

Buenas a todos!
Estoy empezandome a liar con mi nueva novia el asm
Me gustaria que me respondierais 4 temas.
Como desarrollais? AsMSX + BlueMSX ? Alguna sugerencia de configuracion o metodologia de trabajo ? Algun editor preferido?
Podriais poner una "plantilla" de codigo de rom que no haga nada para empezar a ezperimentar a partir des de ahí?
Si no os molesta ire poniendo un poco en este post los pequeños avances que haga, preguntas tipicas etc.
Por cierto, por donde empiezo?
Cargar un sprite y moverlo seria un primer paso?

Venga, gracias por vuestra ayuda!
PD: He buscado un post de este estilo por el foro pero todo ya era mas avanzado. Espero que no sean preguntas ya respuestas...

En efecto, mi forma de trabajar es esa. Edito con UltraEdit al que tengo configurado con la sintáxis del ensamblador del Z80 (una gozada) y luego para compilar simplemente lanzo un archivo compila.bat que comprime todos los gráficos, músicas y datos y llama al asMSX. Por último hago un start de la rom generada y se abre directamente el BlueMSX (o pasa a primer plano si ya estaba abierto).


Yo buscaría algo más simple como el típico "Hola Mundo" en Screen 0 y luego en Screen 1 antes de meterme con Sprites...

Saludos
--
Sph.

Buenas, DoraemonPPC. Me gusta ver que la gente se anima con el ensamblador.

¿Qué configuración uso? Pues la que tu propones: asMSX y BlueMSX. Como editor, utilizo el prehistórico EDIT del MS-DOS, que me viene bien y me permite tener varios ficheros de texto abiertos a la vez. Lo que suelo hacer es tener siempre el código fuente que estoy editando y el MSX Red Book cargado, por si me surge alguna duda. Tienes una copia del MSX Red Book aquí: http://www.robsy.net/tredbook.txt

Como plantilla, no necesitas ninguna, ya que el asMSX hace todo lo necesario para generar la ROM por la patilla. Te dejo una cabecera de ejemplo para que vayas probando:


Como temas para empezar, creo que lo mejor es que te familiarices con el ensamblador del Z80 y la VDP del MSX. Más que nada, porque la gente que viene del BASIC (no sé si es tu caso), cree que la VDP del MSX funciona en modo "bitmap", cuando en realidad funciona siempre en modo "tiled" y el BASIC se encarga de simular el modo "bitmap". Con modo bitmap me refiero a pintar líneas, círculos, etc. Con modo tiled me refiero a que todo funciona mediante patrones de 8x8 píxeles.

Lo que propones, posicionar un sprite y moverlo, es un buen ejemplo. Pero prueba primero a hacer cosas más sencillas, tipo "Hola, mundo!" y semejantes. Otra fuente de inspiración es ver cómo resolverías en ensamblador pequeños programas en BASIC, es decir, cómo lograrías la misma funcionalidad. Y te recomiendo que te pasees por la sección de Snipets del foro y que destripes también los programas de ejemplo que vienen con el asMSX.

Juega mucho con el ensamblador y ten paciencia. Creo que es el mejor consejo. Y si necesitas que te echemos un cable, estamos por aquí para eso.

Esos scripts y config del ultra edit .. podrian pasarse ?

Merci!

Yo me hice uno para el TNIasm, que es el que utilizo. También utilizo el BlueMSX.

La sintaxis de un montón de cosas para el UltraEdit: http://www.ultraedit.com/index.php?name=Content&pa=showpage&pid=40

Los scripts de compilación dependen del programa que esté realizando, pero lo básico sería:

Ostras ... qué put@d@!!! Yo me lo curré desde cero!!! No vi el de Z80 ... :( De todas formas también tengo incluidos los comandos especiales del TNIasm en color rojo.

Perfecto, el coloreo de la sintaxis ya l tengo puesto, el asmsx rulando.
Ahora a ver si configuro el ultraedit para ke tire el asmsx y despues pruebe la rom en el bluemsx.
Gracias por la ayuda!

Ay señor .. pásame tu email que te envío el doc para programar cosas usando el SDCC :)
Yo como siempre llevando a la perversión a todo el que se preste! :)

Aaaaaaah, herejeeee... no pervertirás a más fieles seguidores del assembler!!! ;D ;D ;D ;D

Como es que este pedazo de codigo me escribe 2 A's por pantalla¿
Yo solo queria poner una  :o
Que es lo que hago mal¿
.bios ; Define las etiquetas con las rutinas de la BIOS del MSX
.page 2 ; Sitúa el código a partir de 8000h
.rom ; Define que se va a crear una ROM
.start INIT ; Indica que se ejecutará el código situado a partir de la etiqueta INIT

INIT:    NOP      //empieza mi programa
LD     A,'A'       //Cargo la letra a en A
CALL    CHPUT   //Escribo la A
RET          //Cierro programa

Muchas gracias por escuchar mis preguntas de novato total, pero es que los inicios son muy duros y vuestro ombro me ha gustado  ::)

RET cierro programa? :-)
Yo pa mi que al hacer RET vuelves al CHPut .. o sea ... que vuelves a hacer un Call CHPUT.
Una ROM en principio debería terminar en algo como while (1); o lo que es lo mismo .. JP o JR sobre su misma dirección.

En efecto, con RET sales de una subrutina. Tendrias q poner algo al final como ..

FINAL:
         jr FINAL

.. vamos q en basic seria algo como "100 goto 100".


Sobre la sintaxis, yo uso el TEXPAD con la sintaxis para Z80 q te puedes bajar de msx.org

De todas formas yo aprendi un monton con los textos de "Easymbler" del maestro konamiman. Te los puedes bajar de su pagina y ademas creo recordar q tenian un ejemplo como el q tu buscas.

http://www.konamiman.com/msx/msx-s.html#easymbler

Y ademas en riguroso castellano. :P

Suerte.

Es mi libro de culto  :o

Parece que voy avanzando, ya pongo cadenas de texto, las situo por pantalla, leo teclado, utilizo la pila ....hago programas simples del estilo si escribes esto pasa lo otro y si escribes lo de mas alla pos pasa otra cosa.

Ahora la cosa se pone seria con el tema de los modos graficos, que ayer por la noche ya me quede atascado  :-[

Alguna literatura recomendada para los primeros pasos con la vdp???

Um, igual está sería una buena ocasión para que de paso se fuera preparando un tutorial básico para manejar el VDP... ::)

Me apunto a aprender del tuto  ::)

Bueno, yo sigo preguntando.
Quiero empezar a toquetear el modo grafico, a poder ser compatible con msx1.
Que modo de pantalla me recomendais?
Hay llamadas a la bios que me faciliten la vida?

Como se le mete un sprite al engendro? De que tamaño/caracteristicas pueden ser?
I cargar una imagen a pantalla completa como en las presentaciones de los juegos???

Tantas preguntas y tan pocas respuestas, que dura que es la vida del programador de videos vhs.... ::)

Venga, un cable porfavor...

Hombre, no es tan complicado .. hay mucha documentación en Internet .. tan sólo has de leer un poquito :-)
Sobre el modo de pantalla, pues aquí muchos te recomendarán Screen 2 si se trata de un juego (salvo alguno que los hace en Screen 0 :))
Y sobre el "toqueteo" ya te digo, es fácil, sino te quieres complicar la vida usa funciones BIOS (recomendadas al 100%)
Y sobre las funciones BIOS hay mucha información y son muy fáciles de usar. Animo!

Ahora que lo pienso... he hecho tres juegos y cada uno en un modo de pantalla diferente. Me falta meterme con Screen 3 :D :D :D


En efecto, para comenzar "la BIOS es tu mejor amiga" (tal y como dice nuestro amigo Mr. Kun). En caso de que necesitases velocidad ya tendrías que meterte a programar directamente el VDP pasando de la BIOS, pero esto sólo en caso de extrema necesidad...

Saludos
--
Sph.

Bueno, metiendome en faena y con la lista de llamadas a la bios llego a la siguiente conclusion (seguro erronea)

Con CHGMOD cambio a screen2 por ejemplo.
Ahora pondria la vram en modo de escritura con SETWRT
I copiaria algo de datos con sentido a la VRAM con LDIRVM.

Seria este pseudocodigo correcto para cargar una imagen Screen2 en pantalla?

La segunda pregunta.
Quiero cargar un pobre sprite... las unicas funciones de la bios que encuentro referentes a sprites son: CLRSPR CALPAT CALATR GSPSIZ , me dejo alguna?
En pseudocodigo como cargariais un sprite ???? (n00b mode on please)


Es que estoy atrancado y me esta costando salir adelante  :-\

Imploro vuestra ayuda oh grandes maestros del asm.... :P

Sí, pero LDIRVM ya hace el SETWRT, por lo que no hace falta que lo hagas :D


; Cargamos el patrón del sprite (16x16)
ld hl,datos del sprite en ram (32 bytes)
ld de,direccion de la tabla de patrones de sprites en vram
ld bc,32
call  LDIRVM
; Cargamos los atributos del sprite
ld hl,atributos del sprite en ram (4 bytes)
ld de,direccion de la tabla de atributos de sprites en vram
ld bc,4
call LDIRVM

Muy básico, pero entendible y funcional. Sólo tienes que tener los datos del sprite en ram y transferirlos de ahí a vram con ese pseudocódigo.

Un saludo y ya contarás!
--
Sph.

Y no se, como regla general yo no pensaría en ¿cual es el método para hacer tal cosa o tal otra?. Creo que lo mejor es tener siempre presente cual es la distribución de los datos en la VRAM, donde esta la memoria de pantalla, los colores, los sprites (tanto su forma como sus atributos); así, si tienes todo esto último clarísimo, para hacer algo sólo tendrás que pensar en como modificar esa VRAM en los sitios adecuados y eso sabiendo lo justito de ensamblador no es difícil ;)
¡Mapa de la VRAM ya! :)

He estado empapandome el redbook, que es donde mas o menos esta esto explicado pero sigue sin quedarme demasiado claro.
Me sigo haciendo sopas con las "Sprite pattern Table", la "Sprite attribution Block", los "Mode Registers" y la madre que los trajo al mundo.

En concreto tengo un par de preguntas que no he encontrado respuesta.

- En que direccion empieza la VRAM?
- De la VRAM cual es el segmento destinado a que yo le copie datos de un screen2 a piñon para mostrar una imagen?
- Que tamaño tiene un screen2?
- Podriais ponerme un ejemplo de screen2 en "db"'s de esos? Que secciones ha de tener? O bien el tema de las tablas es solo para sprites?

Espero no aburriros con mis temas, pero vuelvo a estar bien encallado en el tema de bitmaps.


Sin mas me pongo a experimentar con sprites a ver si se me da mejor, que de hecho, creo que esta bastate mejor explicado por la documentacion que he encontrado.

Muchas gracias al que se lea este tocho y un monumento a quien me ayude.

Cero. Y tienes 16k de VRAM - no la confundas con la RAM ...  ::)


Cero.


Definición de caracteres (3 tercios de pantallas de 255 cada uno x 8 bytes = 6144 bytes).

Más otros tres bancos de colores ... otros 6144 bytes.

Aunque realmente, screen 2 tiene 16k  ;) caracteres, colores, sprites, ... Para mostrar una imagen con un Bload,s necesitas las 16k, si no me equivoco ... pero en ensamblador menos.


Sí, ahora te toca cambiar de tercios; de bitmap a tileset.

Pues envías 6144 bytes de redefinición de datos a $0000 y 6144 bytes de redefinición de los colores de esta redefinición de datos a $2000.

Suerte.

Ok, veo que estaba totalmente equivocado, que en msx todo va por tiles o como narices se le llame.

Ale, a ensamblar se ha dicho!

Realmente la VRAM se puede manipular con dos filosofías diferentes, es bueno tener ambas presentes cuando manipules el video. En la primera de ellas, lo haces como en el resto de los ordenadores (p.e: Spectrum) y te limitas a "vpokear" los datos que quieres ver, directamente en la tabla de patrones ($0000-$17FF) con su color correspondiente ($2000-$37FF) dejando sin tocar la tabla de nombres. Así es como puedes hacer conversiones casi directas de los juegos de Spectrum, en las que ni siquiera se planteaban usar la mayor resolución de color del MSX y ya no hablemos de los sprites.
Con la segunda filosofía, usamos de forma más "japonesa" el VDP, aquí ya no accedemos continuamente a las tablas de patrones y de color para repintar el contenido. Nos limitamos incialmente a definir los tres bancos de dichas tablas (puedes meter el mismo banco de carácteres en los tres o meter 1 en cada uno como hace el F1-Spirit). Una vez definidos los 256 carácteres únicamente queda "vpokearlos como queramos en la tabla de nombres, rápido y colorista; pero todo se mueve a saltos ya que la resolución es de tamaño carácter.
Los sprites no tienen ninguna pega, son muy sencillos de usar e independientes de como estés usando la pantalla.

Algunos ejemplos para que te ilustres visualmente ;):

Filosofía 1
-------------

Al 100%  :P: Jack the Nipper (monocromo total)
Al 100%: Astro Marine Corps (usa color y movimiento de carácter; pero sin aprovechar la mayor resolución del MSX)
Al 100% pero con sprites para camuflar un poco: Survivor (cutre), Future Knight (mucho mejor)

Filosofía 2
-------------

Konami: Casi todos hacen uso de sprites a mansalva
Hudson Soft: Casi todos usan sprites de carácter. Muy interesantes de ver
El DoorDoor :): Igual que los de Hudson Soft; pero con personajes bastante grandotes. Muy ilustrativo
Malaika y Exoide-Z: Perfectos ejemplos de como usar el modo carácter (o tile) de manera que se simule un movimiento pixel a pixel. Ambos son referentes en su género.

De tí depende el trabajar con un método u otro (o ambos a la vez).

; VRAM addresses
        CHRTBL  equ     0000h   ; Pattern table
        NAMTBL  equ     1800h   ; Name table
        CLRTBL  equ     2000h   ; Colour table
        SPRTBL  equ     3800h   ; Sprite pattern table
        SPRATR  equ     1b00h   ; Sprite attributtes

Con estas direcciones voy bien?
Necesito saber alguna mas???

El ensamblador con sangre entra!

Imprímete esta tablilla y tenla siempre a mano ;)


------------------------
TABLAS MODOS DE PANTALLA


SCREEN 0 (Text mode, 40 column):
Name table (char positions)     0000-03BF  (0-959)     (See note A)
Character patterns (font)       0800-0FFF  (2048-4095)    (See note B)


SCREEN 1 (coloured text mode, 32 column):
Character patterns (font)       0000-07FF  (0-2047)     (See note B)
Name table (char positions)     1800-1AFF  (6144-6911)  (See note A)
Sprite attribute table          1B00-1B7F  (6912-7039)     (See note C)
Characters colour table (8/byte)2000-201F  (8192-8223)    (See note F)
Sprite character patterns       3800-3FFF  (14336-16383)    (See note D)


SCREEN 2 (256*192 Graphics mode):
Character patterns              0000-17FF   (0-6143)   (See note B)
Name table (char positions)     1800-1AFF   (6144-6911)
Sprite attribute table          1B00-1B7F   (6912-7039)  (See note C)
PixelByte colour table          2000-37FF   (8192-14335)  (See note E)
Sprite character patterns       3800-3FFF   (14336-16383)  (See note D)


SCREEN 3 (4x4 pixel blocks/Multicolour mode):
Character colour patterns       0000-05FF   (0-1535)
Name table (char positions)     0800-0AFF   (2048-2815)
Sprite attribute table          1B00-1B7F   (6912-7039)     (See note C)
Sprite character patterns       3800-3FFF   (14336-16383)     (See note D)





--------------------
Name table (Note A):


Byte:   Expl.:
  0     Pattern number to be displayed in upper hand left corner of screen
  1     Pattern number to be displayed in upper hand left corner of screen+1
  2     Pattern number to be displayed in upper hand left corner of screen+2
  3     Pattern number to be displayed in upper hand left corner of screen+3
  ...



--------------
Font (Note B):   


Byte (+offset):         Expl.:
     0-7                Pattern number 0 (First character)

                        0:      00000000
                        1:      00001000
                        2:      00010100
                        3:      00100010                = "A"
                        4:      00111110
                        5:      00100010
                        6:      00100010
                        7:      00000000

    8-F                 Pattern number 1 (2nd character)
   10-17                Pattern number 2 (3rd character)
   1F-20                Pattern number 3 (4th character)
    ...



--------------------------
Sprite attribute (Note C):


Byte (+offset):         Expl.:
     0-3                Sprite 0 attribute
                       
                0:      Vertical position
                1:      Horizontal position
                2:      Pattern number
                3:      Bit:    Expl.:
                        0-3     Colour code
                        4-6     0
                        7       EC (Early Clock, 1=> Shift sprite 32 pixels
                                    to the left)

     4-7                Sprite 1 attribute
     8-B                Sprite 2 attribute
     ...


-----------------------------------
Sprite character patterns (Note D):


Used like the 8*8 pixel Font in screen 0 when using 8*8 pixel sprites.
When using 16*16 pixel sprites, four blocks of 8*8 pixels is organised like:

Byte (+offset):         Expl.:
     0-7                8 Bytes, Block A
     8-F                8 Bytes, Block B
    10-17               8 Bytes, Block C
    18-1F               8 Bytes, Block D

And the sprite will be assembled on screen like this:

                +---------+---------+
                |         |         |
                | Block A | Block C |
                |         |         |
                +---------+---------+
                |         |         |
                | Block B | Block D |
                |         |         |
                +---------+---------+



--------------------------
PixelByte colour (Note E):


Byte (+offset):         Expl.
        0               Colour code for 8 bits in scrn pos X=0-7, Y=0

                        Bit:    Expl.:
                        0-3     Colour for bit reset ("0") in pattern table
                        4-7     Colour for bit set ("1") in pattern table

        1               Colour code for 8 bits in scrn pos X=0-7, Y=1
        2               Colour code for 8 bits in scrn pos X=0-7, Y=2
        ...

        8               Colour code for 8 bits in scrn pos X=8-15, Y=0
        9               Colour code for 8 bits in scrn pos X=8-15, Y=1
        A               Colour code for 8 bits in scrn pos X=8-15, Y=2
        ...
       


---------------------------------
Characters colour table (Note F):


Byte (+offset):         Expl.
        0               Colour code for patterns 0-7 in pattern table

                        Bit:    Expl.:
                        0-3     Colour for bit reset ("0") in pattern table
                        4-7     Colour for bit set ("1") in pattern table

        1               Colour code for patterns 8-F in pattern table
        2               Colour code for patterns 10-17 in pattern table

Un poco off-topic: JL, el AMC y otras conversiones que hacían scroll a caracteres, ¿realmente usaban caracteres redefinidos o los iban redefiniendo mientras hacían el scroll? Supongo que será lo segundo, puesto que después plantaban sprites soft encima.

Gracias Darth Fistro!
Esa tabla me ha ahorrado bastante tiempo de recopilar información.
La voy a tener a partir de ahora siempre en la mesilla de noche  ;D

No sé si se verá todo claro en esa tabla. Más o menos (en screen 2, que es lo que más interesa):

-La definición de los "caracteres" está a partir de la 0 y ocupa 6kb (6144 bytes). Como la pantalla está "dividida" en tres partes, una empieza en 0, otra en 2048 y la inferior en 4096.

-Para el color lo mismo pero empieza en la 8192. O sea, suma 8192 a lo anterior y obtendrás la dirección de color.

-La "forma" de la pantalla está en la 6144 y ocupa 768 bytes (32x24 caracteres que tiene la pantalla). Aquí se definé qué caracter se muestra en cada posición de pantalla, que va de izquierda a derecha y de arriba a abajo.

-La definición de los sprites empieza en la 14336. Cuidado que el sprite no va definido de izquierda a derecha (hablo de sprites de 16x16, no para los de 8x8), sino primero la parte superior izquierda, luego la inferior izquierda, luego la superior derecha y la inferior derecha.

-Los datos de los sprites a partir de 6912 (4 bytes por sprite). El primer byte es la coordenada y, luego va la x, el nº de plano (multiplica por 4 si utilizas sprites de 16x16), y luego el color.

Creo que por ahora con eso cubres todas las necesidades  :)

6144 ... exactamente. El otro día escribí 6120 ... eso me pasa por escribir bajo ciertos efectos raros ...

Efectos producidos por... ¿estados de ánimo? ¿sustancias líquidas? ¿inhaladas? ¿polvos en suspensión? ...  ;D

Hombre, yo no inhalo nada, sólo aire. Los líquidos son muy buenos para no deshidratarse ... y es que aquí en Alemania hace un calor ...  ::)

Ya puestos, algun alma caritativa que tengas esas tablas para el resto de los modos de pantallas (si lo hay tales tablas, que supongo que si...)...

Salu2.

Te iba a remitir a la página de Robsy; pero me encuentro con que ha desaparecido, ¿que ha pasado? ???

Volviendo al tema, en el manual del TMS9918 encontrarás todo lo que quieras saber acerca del procesador, registros y la organización de la memoria. Lo puedes encontrar, por ejemplo, aquí (http://bifi.msxnet.org/msxnet/tech/). Al final hay unos cuantos documentos muy interesantes sobre el VDP (aunque alguno parece que ha caducado un poco :P).

Gracias jltursan.

Interesante link. ;)

Ultimamaente he estado bastante calladito sin dar la chapa pero vuelvo a la carga!
Debido a no se que gafe que tengo encima he perdido casi todo lo que tenia en mi flash usb, entre ello todo lo de desarrollo de msx.
Esto quiere decir que he perdido los 4 cutre-sources que tenia (en nada lo vuelvo a pillar) y toda la documentación acomulada.

La mayoria de documentación la he podido recuperar, pero la que estava en la pagina del maestro robsy no debido a que ya no esta online.

Des de aqui hago un llamamiento a los cielos para que robsy ponga ese material online para que los mortales como yo podamos acceder a ella o si mas no me la envie al correo para mi regocijo personal. El correo en cuestion es "mi_nick ARROBA gmail PUNTO com"

Esperando que mis oraciones lleguen a buen puerto me despido.

El material sigue todo on-line, aunque se eliminará en breve. Lo único que ha cambiado es la página de entrada, que ha sido sustituida por el mini-blog.

Para bajarte la documentación, utiliza http://www.robsy.net/docs.htm

Y espero que la pérdida sea recuperable. Palabra mágica: backup!

Muchas gracias robsy!
Espero que en nada vuelva a estar donde lo dejé.

Bueno, ha pasado mucho tiempo pero vuelvo a la carga con el tema mas o menos donde lo retomó, peleándome con la VDP.
Una duda muy tonta:
Tengo hecho con un programa al uso (nmsxtiles) unos patrones y lo exporto a asm, obteniendo una coleccion de db's
Este fichero lo incluyo en mi mini programa como ".include mispatronitosydemas"
Una vez hecho esto..... realmente que he hecho? En que sitio de la memòria tengo los patrones?
Es que he intentado copiarlos a la VRAM con algo parecido a :
Pero el asMSX salta como que BANK_PATTERN_0 no es una direccion de memoria....
Como accedo a estos datos para copiarlos a las tablas de patrones-colores de la VRAM para poder velos por pantalla y ser una persona muy feliz?

Gracias a todos y perdon por resucitar un hilo tan antiguo, pero como era mi hilo personal creo que queda todo muy claro :)
PD: Muchas gracias a Jamque que este fin de semana me ha cargado un poco las pilas y me ha enseñado 4 cosillas

Si llamas a una dirección de ese archivo antes de meter el .include me temo que el asMSX no la reconoce. Despues de meterlo no hay problema, creo.

Hace tiempo le tuve que dar bastantes vueltas hasta darme cuenta, pero como las cosas que hago son pequeñitas y decidí meter todo en el mismo archivo pues ya no lo recordaba. No se si estó ya está comentado por algún lado, si no se puede poner como sugerencia para corregir, no Edu?

un saludo.

El código que utilizas parece correcto. Lo único curioso que veo es la cantidad de datos que vas a pasar a la VRAM 0032h, que son unos 50bytes, una cantidad extraña ;)
vendrían a ser unos 6 carácteres y 2 bytes sobrantes. De todas maneras no me hagas caso porque esto no tiene nada que ver con el error que te da.
Supongo que en alguna parte del mismo fichero tendrás algo así (la definición de la etiqueta BANK_PATTERN_0 y los datos db's):


Siendo así debería funcionar. Los datos los incluyes con .include "..."??, quizá haya algún problema con esto, prueba a poner los datos directamente para probar.
El error parece ser que no acaba de reconocer la etiqueta BANK_PATTERN_0.
Asegurate de que las líneas de datos DB no sean demasiado largas. Yo también he creado una aplicación que a partir de imagenes genera los datos DBs,
y al crear líneas de datos muy largas el asMSX me petaba al compilar y daba errores.

En resumen, creo que lo que haces es correcto, más abajo te pongo un ejemplo de código que uso y es clavado a lo que haces ... y a mi me funciona:



Saludos,

Ole, ole!
Ya pongo tiles por pantalla :)
Parece ser que todo era culpa del include.
Lo he puesto directo en el código y sin problemas

Dora,

Los includes han de ser asi :

Es posible que te haga el loco a veces el asMSX diciendo eso...que no encuentro la etiqueta y tal. Yo lo soluciono con un NOP (o dos) en alguna parte por ejemplo delante del .include. No se porque pasa pero parece que a veces se lía a donde apuntar.

Dime el error exacto, pq esto con includes tiene q ir, meterlo a piñon en un solo fichero es desordenado, un estorbo y dará por culo más adelante.

En las pocas pruebas que yo he hecho nunca me ha dado problemas si el .include va antes de las llamadas a sus etiquetas. Al contrario si.

OK
Pongo los includes en la parte de arriba del código y santas pasquas
Ahora otra duda chorra....
Lo que exporto (export to asm) del NMSXtiles solo son las formas y los colores de los tiles.... pero y la tabla de posiciones? (cada posición x,y que tile va ahí)
La he de hacer yo a manita e ir colocando cada tile en su sitio? (seguro que no :P)
Muchas gracias por contestar tan rápido a mis cutre-preguntas

Me auto-respondo.
Ya he visto que en el menu "screen" hay un "export to ASM" o sea que se hace por dos lados diferentes, uno para los tiles y sus colores y por otra banda para sus posiciones en pantalla
Voy a tirarle de las orejas a novi que es quien me esta haciendo las pruebas de gráficos.
Ale, a otra cosa mariposa

Mas preguntitas.
Me gustaría poder cambiar el color del borde azul...
He visto una función de la bios llamada CHGCLR  pero no me queda nada claro como funciona ....

CHGCLR
Address  : #0062
Function : Changes the screencolors
Input    : Foregroundcolor in FORCLR
           Backgroundcolor in BAKCLR
           Bordercolor in BDRCLR
Registers: All

Tengo que definir de alguna manera FORCLR, BAKCLR i BDRCLR? Son direcciones predefinidas en el mapa de memoria?
Muchas gracias a todos!

Sacado del MSXTopSecret2 (http://www.msxtop.msxall.com/Portugues/Projeto_msx_top_secret.htm):


y aquí las posiciones de memoria:

Es muy interesante el pdf este. Está en portugués, pero es muy fácil de entender. Te lo recomiendo. Y si no entiendes algo, pregunta, que no tengo problema en traducirlo.

Un saludo.

Ten, te la regalo : :)

Y para llamarla:

Y au ! sin BIOS :P

Ahi, pasando del standard, luego no te quejes si en alguna maquina no va :P
Pero bueno, que si, q los puertos del vdp no parece haber maquina que sean diferentes. Aunque igual cuando saquen el MSX3...!!  No me hagais ni caso, toi aburrio nel curro una mañana de Semana Sylvia Saint y no hay na que hacer y uno puedo meterle mano ni a la SS ni al Pengo ni a na, y algo tenia que escribir.

si, si  pero a que ya esta solucionado ahora! pues a callar! ;)
vete preparando codigo que ahora los gfx salen como churros!

Conyo, si hasta el novi se reactiva por aquí, ahora SI que siento miedo! Esos SeKTarios, caña, caña!!! A ver que es lo que tramáis!! ;)

Nah, no tramamos nada malo, solo aprender un poquito.
Todo depende de la velocidad de nuestros aprendizajes XD

Ya que estamos, una preguntita.
No me queda nada clara la estructura de la tabla de atributos de los sprites...
Con la tabla de forma de los sprites no hay problema, los cargamos perfectos y llegan bien a la VRAM (el meisei me ayuda mucho en este tema)
Alguna alma caritativa me lo explica de manera simple?
Lo he mirado en todos los documentos que tengo pero alguna tontería hago mal...
Un ejemplo seria de agradecer.
Cual seria la manera recomendada por la FIFA?
Muchas gracias campeones!

Hombre pues la tabla de atributos de sprite es super sencilla. Cada sprite tiene 4 bytes, el primero para la coordenada Y, el segundo para la coordenada X, tercero para el Numero de Patron, cuarto, para el color. Asi tendras una tabla con 4bytes para el sprite 0, 4bytes para el sprite 1... asi en orden.
En MSX2 el byte de color no se usa, se cambia por otra tabla que ahi en otra direccion y que contiene 16bytes por sprite, 1 byte de color por cada linea (si son sprites 16x16).

Carles, ya sabes que yo no tengo problema en traducir del portugués. Por lo que, si necesitas algo, no es necesario que molestes a e_sedes :P



Va! a ver que sacamos de todo esto! Ya iréis viendo.

P.D: Xaiaaaaaaaaaaaaaaaaa!!! ;D ;D ;D ;D ;D ;D ;D ;D

Me estoy haciendo daño con una tonteria del mil.
Hay alguna manera facil rollo BIOS para poner el tamaño de sprites a 8x8 o a 16x16?
Muchas gracias majos!

Fórmula "buena":

- Leer la copia en RAM del registro correspondiente del VDP
- Cambiar de estado el bit correspondiente
- Escribir el valor al registro de VDP

Se puede hacer todo con la BIOS, sin hacer pupa a nada.

Algo así como:


RG1SAV equ 0F3E0h
WRTVDP equ 0047h

SET_16x16_MODE:
  ld a,[RG1SAV]
  or 02h
  ld b,a
  ld c,1
  call WRTVDP
  ret


Una única advertencia: el valor de RG1SAV será correcto si todas las escrituras a registros del VDP se han hecho a través de la BIOS. Por lo tanto, si todo funciona con la BIOS no tendrás ningún problema.

Le pego un ojo mañana con la mente despierta.
En principio soy buen chico y lo hago todo con la bios sin hacer marranadas (ya me cuesta bastante como para hacer filigranas)
Gracias por la ayuda

Entendido y chutando a 16x16.
A parte de esto hay algo que estoy haciendo muy mal, los sprites en el SPGT me salen perfectamente colocados en la posicion 0 y 1 (tengo solo 2 sprites) pero en el SPAT se me van a la posicion 4 y 5 y yo creo que lo envio a la posicion 0 y 1 ....
Ay madre la que toy liandoooo :)
Con esta calor y yo calentandome el tarro
Seguiremos reportando de nuestros minimos avances

Me autorrespondo... ya he conseguido poner sprites donde me da la gana y del color que quiera :)
Ahora toca empezar a hacer fechorias. Esta noche tengo un grafista sequestrado.
Voy a ver que tal va el ensamblado condicional.