Karoshi MSX Community

Buenaaas, es que me he levantado porculero y me he dicho: vamos a abrir un topic de esos que molesten, jejeje  ;D

Veamos, ¿hay alguna alternativa a ldir (usando sólo la BIOS) o es ésta la opción más rápida a la hora de transferir bloques? Lo digo por si hubiere algún buclecillo más optimizado, aunque me da en la nariz que por la simpleza de la instrucción me voy a tener que conformar con eso.

Comento lo de la BIOS porque yo de interrupciones ni idea (sólo coitus interruptus me suena), y no sé si al utilizar outs perdería la música del Caruso.

Y ya de paso, intentaré ver la rutina de instalación del replayer del Caruso para ver si me entero de cómo funciona una interrupción, y de paso, ver si puedo hacer lo siguiente: utilizo 8 sprites y quiero conectar y desconectar alternativamente los 4 primeros y los 4 segundos para evitar la regla del 5º sprite. Supongo que debería mandarlos por tandas a la posición vertical 209 para que desaparezcan de pantalla y restaurarlos en la siguiente interrupción. ¿Es ese el enfoque correcto?

Bueno, thanx a pares y todo eso  :D

Tu nunca molestas, Juanma ;)



Si, hay opciones más rápidas de transferir bloques de datos a VRAM. Échale un ojimetro a este thread, donde verás varias opciones acerca de este tema: http://karoshi.msxgamesbox.com/index.php?topic=305.0



No te preocupes. Cuando salta la interrupción, se detiene todo, y se guardan hasta los registros: solo tienes que indicar cual es la rutina de interrupción y sin más, ésta se lanzará al comienzo de cada "frame". Lo que si que tienes que controlar es CUANDO mandas esos OUTs (preferiblemente inmediatamente después de la interrupción).



Te vuelvo a remitir a otro thread interesante sobre la regla del quinto sprite y como acometerlo desde distintos enfoques: http://karoshi.msxgamesbox.com/index.php?topic=427.0

Como se nota que hemos hecho novillos durante mucho tiempo, eh?... tsk, tsk, si es que...  ;). Quiero empezar a ver llover producciones de crappy pero ya! :D... y de paxanga también!

(pero, ¿por que me pegas, si sabes que me gusta?) kun >  :spank: < viejo_archivero (jo, es que hacá tiempo ya que no lo hacía...)

Veamos... me pongo la armadura y a combatir el topic molesto :P


¿Transferir bloques a donde? Si hablas de RAM a RAM, ldir es la forma más sencilla (que no la más rápida) de transferir bloques. Si quieres mejorar la velocidad tendrías que desenrollar el bucle del ldir poniendo unos cuantos ldi a saco y encerrándolos dentro de un bucle más grande.


Por este párrafo deduzco que quieres transferir bloques de RAM a VRAM. Para eso la BIOS es MUY MUY LENTA... Pregúntale al viejo_archivero si no ;) Ya hemos hablado en este foro largo y tendido de los ciclos de espera mínimos entre transferencia y transferencia a VRAM...

De todas formas, te aconsejo empezar por usar la BIOS y luego, si tienes necesidad de más velocidad, puedes mirar la forma en la que se transfiere realmente a VRAM (y en último caso... puedes hablar conmigo ;D)


Yo haría otra cosa. Si sólo tienes esos 8 sprites y quieres que en un frame se vean 4 y en otro otros 4, lo más rápido es tener dos tablas de atributos de sprites en VRAM (caben sin problemas). Entonces trabajarías como si tuvieras 64 planos de sprites y en cada frame cambiarías la tabla visible, por lo que sólo estarías viendo 32 sprites al mismo tiempo. Prueba...

Saludos
--
Sph.

Eso eso, producciones de Crappy!!! :D Dale dale fuerte!! Ah no que soy yo!
 :'(  Que malo eres, no me des en toda la cabeza, que bastate tonta la tengo ultimamente...  Paxanga hace lo que puede. Steven va currando, pero yo estoy bastante fuera del planeta hace un tiempo :P No solo para el MSX, imaginaos, si ni siquiera he visto los ultimos 6 capitulos de Humor Amarillo!!!  :-[
Na, necesitaba un cambio, todo eran listados interminables de instrucciones ASM...cada dia. Asi que me he tomado un señor respiro. Pero sigo en el ajo poco a poco ;) No sus vais a librar...

En cuanto a Darth, a saber pa que querra algo mas rapido que el LDIR... ;) Miedo me da. Y en el tema sprites, hubo un threat muy interesante sobre rotacion spritera :) Merece la pena echarle un ojo.

¡Mil gracias a todos!  :D

Antes de que se me olvide, el sr. MSXKun dale que dale con el  :spank: a todo kiske pero el tío tiene cuentas pendientes con sus juegos, jejeje...  ;D

Pues sí, pensaba en transferencias RAM->RAM, y es que necesito copiar al menos 2 tercios de pantalla de una forma rápida, y luego si hay por ahí otro topic donde transferir a VRAM pues ya mato dos pájaros de un tiro  :D

Me quedo más tranquilo con lo de la música. O sea, sólo tendría que poner un halt antes de la rutina de transferencia y ya está, vamos, como lo que hacía con call LDIRVM  :)

Miraré lo de las interrupciones y gracias por las ideas. Voy a plantearme lo de las dos tablas. Gracias de nuevo  :-*

Es que acabo de hacer una rutina de scroll de texto píxel a píxel como el snippet de Edu, introduciéndole "desde la derecha de la pantalla" caracter a caracter y luego rotando todo. He pensado ampliarlo para hacer un scroll completo de pantalla, pero creo que eso en un juego no sería muy jugable que digamos  :-\

A lo que voy, como estoy con cosas spectrumeras, y eso de los sprites software es coser and sing  ;D ahora necesito saber cómo los joíos por culo de Dinamic, etc. volcaban al menos los dos tercios de pantalla (en un buffer donde la almaceno) a la VRAM. Sé que había parpadeo y era lento, pero igual hay otra forma como sólo transferir las partes de pantalla que cambian o algo así.

Necesito velocidad de transferencia RAM->RAM además porque estoy liado con un filmation en plan Head over heels, y tengo funcionando el muñeco y escenario, ocultaciones y demases, pero necesitaré buena velocidad para transferir toda la pantalla, aunque ahora mismo estoy con pruebas poniendo un montón de halts para que vaya despacio adrede para así poder visualizar mejor fallitos que se pasarían de otra manera. Quiero decir que no he probado "a saco" cuál sería la velocidad máxima de la BIOS.

Tengo pendiente el tema de las colisiones. Supongo que habría que hacerlas píxel a píxel, aunque hice una rutina y rien de rien, eso no funcionaba  :-\ Y además supone otro buffer de 6kbs en memoria sólo para máscaras de detección de choque, lo que me parece un despilfarro total y supongo que habría otra manera de hacerlo. Para otro tipo de juego podría usar detección de colisiones por caracteres como siempre, en un buffer que contuviese una pantalla paralela de 768bytes sólo de caracteres, pero eso ya no me resulta complicado.

Eso sí, preparaos para algún que otro juego "a la antigua usanza" Sinclair, jejejeje (no me puteéis mucho, plís)  ;D Lo importante es el reto que me supone entender mejor el sc2 y poder hacer las cosas con las que babeaba desde chico, jeje  ;)

Si no es mucho pedir, me gustaría saber como haces esto.

No tengo mucha idea, Jos'b, pero creo que se refiere a instalar la interrupción, parcheando el gancho en la ram donde se aloja la dirección de la misma.

Es lo que más o menos deduzco de este trozo de código del Caruso, donde se instala el reproductor (con permiso de Mr.Robsy):

INSTALL_INTERRUPTION:
; Install interrupt handler
;----------------------------------------------
; Disable interrupts
di
; Interrupt BIOS entry point
ld hl,0FD9Fh
; Address of the new interruption routine
ld bc,INTERRUPTION_HANDLER
; Instruction "CALL"
ld [hl],0C3h
; Address stored
inc hl
ld [hl],c
inc hl
ld [hl],b
; Enable interrupts
ei
; Done
ret

Una cosa rápida, que necesito para mis planificaciones:

¿Cuál es la direcciónl tope en la página 3 (en decimal, plís) que puedo usar en ensamblador?

¡65535! :D

Bueno, si no te quieres comer la cabeza no uses mucho más allá de la 62208 (no se como te aclaras con el decimal :o)

Hay una variable RAM que te lo dice HIMEM
Si no usas DISKROM -> #0xfc4a
Y si usas DISKROM -> #0xf349

A la saca.

Gracias, lo que yo no entiendo tampoco es cómo podéis entenderos en hexadecimal  ;)

Supongo que no estaré usando la diskrom  ??? pero me ha sorprendido saber que se podía escribir tan alto (64586). Creía que a partir de la 60000 ya era tierra peligrosa... mejor que mejor, más RAM para la saca  :)

¡Ojo!, que la dirección que Nerlaska ha puesto es la de la variable que contiene la dirección más alta usable por el programador, no la dirección en si misma. Si somos estrictos, esta dirección en un MSX sin periféricos conectados es $F380 (62336), que es lo que normalmente contiene HIMEM. Si el equipo tiene hardware extra y este es inicializado, esta dirección decrece y se pueden perder un buen puñado de Kbs.
En el caso de las ROMs, yo no me complico la vida e incluso respeto la pila que suele estar inicializada un poco más alla de $F300, total, no va de unos bytes... :)

Échale un ojo a este hilo del MRC en el que se hablaba también de este tema:

Memory/System variables (page3) (http://www.msx.org/forumtopic6985.html)

Se me olvidó meter los paréntesis :) Gracias JL ;)

Gracias. Regla de oro entonces: no pasar de la 62000 y listo  ;)

A ver, tenía entendido que estas instrucciones son equivalentes:



y sin embargo la primera suma correctamente y la segunda no. ¿Qué error de borrico mayúsculo estoy cometiendo, please?

Jarl! El error tiene que estar en otro lugar, porque el código es funcionalmente equivalente: incrementar en uno el contenido de la posición de memoria NUM. Pregunta: ¿estás usando asMSX? Ten en cuenta que la sintaxis que usa para indirecciones no es usada por otros ensambladores, que prefieren usar los paréntesis normales (sintaxis oficial).

Pues equivalentes, equivalentes no lo son del todo..., basicamente la diferencia es que en la segunda A no queda inicializado (¿no lo tratarás de usarlo después verdad? ;)) y que los flags no se ven alterados, por lo que no valdran chequeos del flag C y tal...
Por lo demás en ambas incrementas [NUM] fijo, fijo. :)

JL, déjame que disienta:

INC [HL] no afecta al acumulador, registro A, pero sí que actualiza el registro de banderas de estado F, por lo que sí podrás realizar todo tipo de comparaciones del tipo Z, NZ, C, NC, etc.

Las que no actualizan las banderas son las instrucciones INC/DEC con registros de 16 bits, es decir, INC/DEC HL/BC/DE. A todos los efectos, INC/DEC [HL] tiene consideración de 8 bits, por lo que sí que actualiza banderas.

Y sigo sin saber qué puedes estar liando, Juanma.  ???

Es que quién puede escrutar los misterios de la mente del Darth?  ;)

En la primera HL no se modifica, pero A si. Y en la segunda modificas HL, pero no A. Todo depende de lo que hagas después.

Ups, pues es verdad  JL> :spank: <Z80

Pues ya sólo queda la opción de que el registro A se use a continuación esperando contener el valor en cuestión.... ::)

Buenooo...la polémica de los INC  ;)

No, Edu, no hago nada raro. El fallo estará en otro sitio, pero no sé donde, porque ese es exactamente el código que uso y luego no intento comparar con A ni nada de eso, ni leo banderas, ni nada. He vuelto a la opción del acumulador, y funciona. Ya veré luego de qué se trata. Estoy liado con la equivalencia que me propuso Jon: representación 2D-representación 3D y tenía problemas al renderizar en 3D, pero ahora todo resuelto. Tengo que ver cómo puedo hacer saltar al personaje.

¡Gracias!  :)

Ya era raro que ayer no tuviera una duda técnica, así que haré dos preguntillas para recuperar el tiempo perdido  ;D

-Después de 25 años con el MSX... ¿alguient puede explicarme para qué puñetas sirve el color 0?  :-[

-¿Puede usarse en screen 2 una tabla de colores de 768 bytes como en screen 1? ¿Algún cambio de BASE o cosas raras del estilo?

¡Gracias!  :-*

No estoy muy seguro pero creo que hace de color transparente cuando le metes vídeo ... Además coge el color de fondo ... Normalmente es "negro", pero si cargas una imagen con el color azul de fondo creo que ese "negro" se vuelve azul ... Tampoco me echéis mucha cuenta.  ::)

Curioso pues, y misterioso... ¿hasta cuándo seguirá siéndolo? (hasta que alguno de los gurus asome la cabeza por aquí)  :D La verdad es que lo del color 0 no viene bien explicado en los manuales que he visto...  :-\

El color 0 se puede aplicar a un sprite, para que parezca que no está ahí, pero realmente está. Con lo que las colisiones con dicho sprite aún funcionan, y aún más, puedes usarlo en marcadores de forma estratégica para la ocultación de sprites, ya que también permanece activa la regla del 5º sprite, aunque parezca que el sprite no está (ver Phantomas Saga: Infinity, cuando Phantomas esta muy arriba o muy abajo, parece que Phantomas se esconde tras caracteres, y lo que realmente ocurre es que "sufre" la regla del 5º sprite con sprites situados en layers superiores y de color 0). También es muy útil para hacer parpadear un sprite cuando no quieres alterar su X ni su Y, solo cambiando el byte del color de pronto no es visible... tan solo por las aplicaciones que tiene con los sprites, el hecho de tener un color 0 transparente *mola mucho*  8)

El color 0 estaba previsto para mezclar otras fuentes de video con la señal del VDP. De hecho el TMS9918a original tiene un pin para recibir directamente la señal de otro vdp y hacer configuraciones multivdp de manera muy sencilla. El 9929a ya no tiene esa función, y la mezcla de señales ha de hacerse con un circuito externo.

Es una pena que no se mantuviese esa funcionalidad y que el MSX no lo integrase en el conector de cartucho, como lo hay para audio. ¿Os imaginais cartuchos con vdp integrado o cosas así? EL resultado podría ser impresionante  :o  :D

un saludo.

Pues eso, que todo vale respecto al CERO.

- Sprites: el sprite es transparente (invisible) pero sigue ahí. Útil para ocultación y colisiones.

- Fondo: el color 0 es equivalente al color del BORDE. Es decir: si cambiais el color del borde, cambiaréis todo lo que esté pintado de color 0 a ese color.

El tema de la superimposición sí pasa también por el color 0, pero activando el bit de video externo del VDP. Con el Pioneer Palcom PX7 he hecho algunas pruebas en este sentido y es muuuuuuuuuy divertido experimentar. :)

¡Gracias a todos!

Ya veo que estaba equivocado, resulta algo muy útil  :) ¿Hay alguna bandera para ver si se producen colisiones entre sprites?

Y respecto a lo de la tabla de 768 bytes, ¿es posible?

Edu, menudo afortunado por ponerle las zarpas a un trasto así  ;) Por cierto, ejem, ejem... ¿qué tal un snippet con esa rutina de transferencia a VRAM?  ;D ejem, ejem...

Claveliiiitos, claveliiiiitos (la tuna de la facultad de Derecho de Valladolid bajo la ventana del Sr.Robsy y Darth cortejándolo)  :-* :-* :-*

Pozi. Quoteando desde el Portar MSX Tech Doch (http://www.work.de/nocash/portar.htm):


 

¡Gracias!  :)

Preguntilla rápida:
-¿es equivalente sra a sla? (solo que desplazando con carry a la derecha?

Otra rápida: las rutinillas de transferencia rápida a VRAM que he visto desactivan las interrupciones para hacer OTIR y demases, pero mi duda es: si la transferencia es grande y dura más de 1/50 de segundo, no se activa la interrupción correspondiente y te puedes quedar sin música o lo que sea, ¿verdad?

La última y me acuesto ;) : ¿es más rápido jr nz/z que jp nz/z si la condición no se va a cumplir?

Un JP NZ es más rápido.

Bueno, casi te respondes tú mismo a tus propias preguntas ... si te pasas de un barrido de pantalla para hacer algo se va todo al carajo; música, movimiento suave, etc ... en caso de tener que actualizar el PSG y demás datos (como nuevas coordenadas y ordenadas en VRAM) a cada barrido.

No sólo. En MSX1 si te pasas del retrazado no puedes utilizar OTIR porque es una instrucción demasiado rápida para el pobre VDP. Si te pasas corres el riesgo (muy muy alto) de que los gráficos se corrompan.

Saludos
--
Sph.

Y aun más, no hay porque desactivar las interrupciones cuando se ejecuta una transferencia a VRAM, sólo es estrictamente necesario cuando estás programando la dirección de escritura o lectura al VDP, a partir de ahí puedes mantenerlas activadas.
El Z80 chequea la existencia de una interrupción tras ejecutar cada instrucción, el caso del OTIR es especial ya que no hace chequeo cada vez que se ejecuta un OUTI; asi que se trata de una operación atómica desde el punto de vista de las interrupciones. Si se produce alguna cuando se está ejecutando, saltará inmediatamente al acabar el OTIR. Esto unido a que las iteraciones máximas permitidas en un OTIR son 256, hacen que como mucho se produca un ligero retraso en la ejecución de la interrupción.
El problema surge, como ya te ha comentado Sapphire, cuando todo está medido, encajado y sincronizado. Si por alguna razón se te ejecuta un OTIR gordo y te descuadra el tiempo usado en cada fotograma; pues nada si desbordas el tiempo total tendrás parones, saltos y demás impertinencias. En el peor de los casos puedes acabar incluso con cuelgue si en la interrupción no tienes mucho cuidadín con la pila y los registros que guardas en ella.
Y por supuesto, en MSX1 hay que tener muy clarito donde y como se usa el OTIR, que por regla general no funciona nada bien... :P

Pues nada, como rectificar es de sabios.... :P
El OTIR si que es interrumpible; así que bueno, habrá que llevar cuidadín de, si no se han desactivado las interrupciones durante su ejecución, que el código que ejecutemos en la interrupción no acceda al VDP porque en ese caso nos cargariamos el OTIR.

Eso me parecía a mí, que es interrumpible al igual que el LDIR...

Gracias por las lecciones magistrales, ahora sólo tengo que encontrar la forma de mandar al menos 1,5kb por frame  :D

¿Tanto? :o :o

¿Tan poco?  ;D  ;D  ;D

Hombre, el máximo es mayor, pero si quiere integrar ese volcado en un juego va a costarle, porque es mucha transferencia por frame...

Exacto  ;) Lo ideal sería mandar 6kb al menos por cada frame (o mejor 12, así incluimos el color)  :D

¿Pa cuando un OUTIW? ;D

Pero, ¿sería viable mandar 1,5-2 kb por frame?

Leete en este hilo (http://karoshi.msxgamesbox.com/index.php?topic=668.0) los apartados "Acceso contenido a la VRAM" y "Diferencias en el acceso al VDP en equipos con refresco 50Hz/60Hz". Seguro que de repente empiezas a ver por donde van los tiros... ;)

O sea, que es posible enviar 1,5kb al menos en máquinas PAL, ¿verdad?

Sí, pero no mucho más allá de 1,5 KB. De hecho, con 2 KB de transferencia, una máquina a 60 Hz ya peta. Eso sí, usando OUTI / NOP / NOP para asegurarnos de no perder nada, incluso durante la interrupción.

De todos modos, pintar la pantalla entera, incluso sin colores, supone 6 KB, con lo que necesitarías 4 interrupciones para pintarla entera. Suponiendo que pudieras "calcular" la pantalla en ese tiempo, tu juego funcionaría a 50 / 4 = 12,5 FPS en el mejor de los casos. Para muchos juegos, esta velocidad sería insuficiente.

Única solución válidamente aplicable y universal: buen diseño de partido :P

¿partido?  ??? :)

Supongo que habrá querido decir "de partida" o sea, partir de un buen diseño.

¿Será que Robsy se nos ha aficionado al fútbol?  ;D ;D ;D

ANATEMA.

No caerá esa breva, muchachos. Mi afición al fútbol acaba donde acaba el KONAMI'S SOCCER. Si me preguntan de qué equipo soy, respondo convencido y sin atisbos de duda: EAGLES! El mejor equipo del mundo pese a que todos sus jugadores tienen bigote  :D. Y son unos auténticos cracks: llevan 22 años jugando los mismos titulares y cobrando lo mismo. A ver si toman nota...

¿Quieres decir que no habrá un Karoshi's Soccer? ;D ;D ;D ;D

buff, solo de pensar en el trabajo que conlleva, me canso  :-\ ;)

Vamos, Jon, que eres el maestro de los sprites a base de caracteres  ;) Apoyo ese Karoshi's soccer también  :D

Bueno, vuelvo al ataque. A ver...

Supongamos que tenemos dos sprites A y B uno justo encima del otro (de 16x16), o sea, 16 píxeles por encima.

Ahora colocamos un tercer sprite a su lado y en medio de los dos, de forma que pille 8 píxeles de cada uno de los dos sprites.

La pregunta es: para la regla del 5º sprite, ¿ese caso cuenta como tres sprites en línea o sólo como dos, ya que con el tercer sprite sólo se cruzan en horizontal 2 sprites?

¡thanks!  ;)

(os preguntaréis cómo cojones tengo la cara de programar una segunda parte de los Goonies sin tener ni p*ta idea de cosas tan básicas. Pues sí, señores, la vida es así)  ;D

Dos. Normalmente cuando veas sprites con tres colores es que han usado este truco...  ;)

A new question: ¿las funciones DISSCR y ENASCR también pueden sincronizarse con el barrido mediante halt?

Jeje, ¿que estarás maquinando?

Si, puedes desactivar la pantalla sincronizando con el barrido; pero no suele tener mucha utilidad.
Haciendo salvajadas con la temporización del barrido puedes extender el tiempo de VBlank sacrificando lineas visibles ;).

De verdad que me intriga lo que pretendes...  nnchks:)

Jejeje, ¿por qué eres tan mal pensado? ;D

Tan sólo quería saber si el barrido sería "instantáneo" o se pordría apreciar en algún momento el borrado de la pantalla. En el emulador no se aprecia bien.

Estoy ahora mismo de MSXtremo total :)

¡Vuelvo al ataque!

No puedo probarlo ahora mismo, pero, si quiero multiplicar HL por 32, ¿podría hacerlo rotando a la izquierda HL cinco veces de la siguiente forma?


Thanks!  ;)

No sé qué tal te iba a ir el tema de la bandera de acarreo. Ten en cuenta que al hacer RL de un bit, te puede salir por la izquierda, con lo cual tendrías que recuperarlo por la derecha en el siguiente bit.

A mi, que soy más expeditivo, me gusta la solución siguiente:

LD B,5
@@LOOP:
ADD HL,HL
DJNZ @@LOOP

¿Qué tal así? ;)

La versión de robsy es más rápida, pero aún puede mejorarse :D


Ocupa más, pero ahora sólo se usan 55 ciclos en lugar de 120... ;D ;D si hay espacio suficiente, desenrollar los bucles es muy recomendable :P

Y me temo que hasta ahí se puede llegar... :)

Pues veamos...

or a pone el flag c a cero

RL L toma el carry, rota a la izq y "suelta" un nuevo carry

RL H toma el carry anterior, rota H y suelta un nuevo carry, que no uso

Y repito todo 5 veces: debería funcionar, ¿me equivoco?  :)

¿Ocupa más? Creo que son 5 bytes ambas, ¿no?

He dejado el tema del DJNZ para poder hacer multiplicaciones por potencias de dos entre 2^1 (2) y 2^15 (32.768).

Evidentemente, si lo que quieres es velocidad, como dice Sap, hay que desenrollar todos los bucles al máximo.

Eeeem... no se por qué me había empeñado en que add hl,hl ocupaba dos bytes... ::)


Nada, nada... eso se puede arreglar como sigue:


Rutina que ocupa 16 bytes y es más rápida que el bucle :D


cuanto más mejor :D Podríamos resumirlo en la siguiente máxima: "para llegar antes no hay que enrollarse" ;D ;D ;D