Karoshi MSX Community

Desarrollo con el RuMSX, y sucede que a veces, si hago un "soft reset", cuando la rom se vuelve a inicializar, algunos enemigos no aparecen o aparecen "glitches" en la pantalla. Tengo que hacer entonces un "hard-reset" (que se supone borra todo el contenido de la RAM) y el juego vuelve a comenzar bien. Pensé que era debido a que la RAM no se borraba al resetear y tal, pero mi sorpresa vino al probar en el blueMSX y comprobar que pasaba lo mismo, y además el blue no da opción (que yo sepa) de resetear borrando la RAM, con lo que me pregunto, ¿usáis alguna rutina que borre la RAm al principio de vuestros juegos?  :)

Programando en ensamblador no vale hacer suposición alguna sobre el contenido de las posiciones de memoria. Por lo tanto, inicializa la RAM que vayas a utilizar siempre. Como medida higiénica, lo que hago es escribir ceros en toda la RAM utilizada por el programa. Para ello, puedes usar cualquier rutinilla con bucle. Por mi parte, uso algo parecido a lo siguiente:


Si tienes prisa, también vale lo siguiente


Como siempre: cada vez que escribo un poco de código, se me ocurren mil formas mejores de hacerlo. De todos modos, es una mala cosa optimizar rutinas que no son críticas: uno se vuelve obsesivo y no consigue grandes mejoras. Vale, la segunda rutina ocupa sólo 11 bytes, mientras que la primera ocupa 15. Además, también es más rápida.

Pero Robsy, ¿no es mejor hacer lo siguiente?


Bastante rápida y elegante, ¿no? :D

Este es el típico problema de falta de inicialización de los valores de las variables ::) ::)

Interesante técnica, sí señor. Copia sincrónica con arrastre del 0. El único problema -puesto a buscarle problemas- es que ocupa 13 bytes. Eso sí, supongo que es más rápida que la solución propuesta.

En cualquier caso, en lo que todos estamos de acuerdo es en que resulta imprescindible inicializar la RAM antes de hacer cualquier otra cosa en un programa.
 

Pues la técnica la aprendí de un listado en CM que salió en alguna MSX-Extra ó MSX-Club ;D ¡Para que luego digan que no servían para nada esas revistas!

Por cierto he puesto en forma de Snippet la rutina que utilizo en el Namake's para rellenar una zona de memoria con determinado byte.

Saludos
--
SapphiRe

Gracias por compartir código, Sap! Aprovecho para animaros a todos a escribir/mejorar/depurar/solicitar snippets.

Acabo de leer en una msx-extra también que es mejor un simple bucle a ese método (lo siento, Sapphire, no me pegues) ;) Gracias por vuestras rápidas respuestas.

Sí,eso de dar por supuesto que la RAM va a estar lista para el abordaje me ha dado algún que otro susto. A partir de ahora lo evitaré, mil gracias a ambos :)

Si puedes decirme en qué MSX-Extra lo has leído te lo agradecería. De todas formas no me cuadra en absoluto, hagamos cuentas:

ldir consume 21 ciclos por cada byte que copia, menos por el último que consume sólo 16

ld [hl],r consume 19 ciclos
inc hl consume 6 ciclos
dec bc consume otros 6 ciclos
ld a,b consume 4 ciclos
or c consume 4 ciclos más...
jr consumiría 12 ciclos salvo si no se cumple que serían 7

sumando: 19+6+6+4+12 = 47 ciclos para todos los bytes salvo para el último que serían 5 menos, es decir 42

Es decir: ldir 21/16, bucle 47/42...

No veo por qué es mejor el bucle, la verdad...

Para salir de dudas hay que comparar estos métodos en un MSX real. ¿Cómo? Por ejemplo midiendo el grosor de la línea azul que generaría el siguiente código:


Y primero probamos a inicializar 8kb's con una técnica y luego la misma cantidad con otra técnica. La línea azul que resulte más gruesa indicará la técnica más lenta. Ahora mismo no tengo acceso a un emulador (puede que en una horita o así...), ¿alguien puede probarlo?

Saludos
--
SapphiRe

Es que aquí se te fue la mano, en realidad son 7 ciclos; pero ni por esas, LDIR sigue siendo más rápido que la segunda versión del bucle :

7+6+4+12/7 = 29/24

frente a

21/16

del LDIR

Y ya puestos es más rápido (y clásico) esta variante :


Ya puestos a sentir el vértigo de la velocidad... ;D

Ya digo que no es crítica, porque yo no tengo ni p.idea, pero me llama la atención que en la msx-extra y la club, en algunos artículos dicen una cosa y varios números después otra distinta (que si se puede sintetizar voz, que si no...) y sobre los artículos, no sé si fiarme del todo, por eso lo digo (uno de scroll píxel a píxel resultó ser al final scroll en la tabla de nombres, o sea que píxel a píxel nada). He guardado el lote en al armario, mañana lo miro, pero era un artículo que tenía un dibujo de esos clásicos en blanco y negro con un explorador mirando con lupa unas inscripciones egipcias. Trataba de la optimización en general, y se hablaba del asm del Z80 (que si or a es mejor que cp 0, etc.). Mañana te digo el número con exactitud, pero no era ni muy viejo ni de los últimos.

Ahora estoy grafiqueando, pero mañana pruebo a limpiar la ram y dejarla como una patena ;)

Cierto... lo miré en una tabla que hay en la web ( http://www.ftp83plus.net/Tutorials/z80inset1A.htm ) y las líneas no están perfectamente alineadas. Pero lo cierto es que LDIR es más rápido que un bucle, ya que te ahorras, además, el tener que acceder a la RAM para leer el código de la siguiente instrucción.

Saludos
--
SapphiRe

Me fío más de tí que de las revistas, Sapphire :) Lo haré con ldir, pero de todas formas te dejo el nº de la extra:

nº 34, call XIII

Ejercicio:pon 200 bytes consecutivos a cero.

Solución:

ld hl,direccion
xor a
ld b,200
bucle:
ld (hl),a
inc hl
djnz bucle

más rápido y más corto que:

ld de,direccion
ld hl,direccion+1
ld bc,200
ld (hl),0
ldir

(ya toi de vuelta) ;) por eso me sonaba raro lo del ldir, pero ahora todo aclarado. Habrá que andar ojito con las revistas  :-\

¡Gracias de nuevo!  :)

  No te fíes de mí, mejor comprueba las cosas por tí mismo :) Fíate de las matemáticas, que a estos niveles tan elementales no fallan (pero si subimos un poquito... madre mía la de agujeros que tienen).


  Octubre de 1987, le echaré un vistazo en casa porque ese número lo tengo (de hecho sólo me falta el 39, ¿lo tienes repe? :D)


  Desde luego que hay que andar con ojo con ellas. Seguro que muchas veces la información es correcta, pero en otras ocasiones pueden contradecirse a sí mismos y meter la gamba. De todas formas para estar absolutamente seguros puedes meter esos trozos de código en el código que posteé ayer y que cambia el color del borde (en lugar de 200 bytes pon 8000). El que tenga una franja azul más gruesa es el más lento.

  Con el cálculo de ciclos desde luego sale ganando el ldir y, además, si cada instrucción precisa de un ciclo extra... ya me dirás cuál de las dos soluciones tiene menos instrucciones críticas :D ¡Ante la duda hay que ir a los ciclos! O en su defecto al color de borde :D
Saludos
--
SapphiRe

Lástima, el 39 no lo tengo, pero te lo daba encantado :D

Voy a buscar en internete alguna tabla con los tiempos de cada instrucción, a ver si optimizo un poco, que esto es un spaghetti assembler total  :P

Con lo del bucle, pues ldir y ya está. Total, tampoco creo que el tiempo de ejecución en esto sea muy crítico, como dice Edu. Voy a probar un scroll en screen 2 esta tarde a ver qué sale, ahí si que me va a hacer falta rapidez (y usando la bios) :D

Un poco más arriba tienes una tabla con todos los tiempos, sólo que las fonts no son muy proporcionales entre columnas y lían un poco. Si no te apañas te envío una que tengo por casa.


¿Píxel a píxel? Yo ya tengo esa rutina :D y a colores :D

¡Pero sólo vertical, sólo vertical!  ;D

En cuanto a Z80, referencias, tiempos, etc. mi recomendación es ésta (http://www.robsy.net/z80undoc.pdf). Pero no os olvidéis de añadir el retardo adicional que introduce el amigo MSX!

¿Quién lo dice? ::) ::)

Jeje, te he pillado, reconócelo  ;D ;D

No lo reconozco en absoluto porque no es cierto :D

Merde alors!, ¡como se escabulle el condenado!  2gf:)

Soy experto en ese arte, me enseñaron bien mis maestros :) :)

Que pelea :P
Se  nota q no hay mucho curro que  hacer!  ;D
Bueno yo tambien he tenido la mañana tranquila y he aprovechao pa hacer una rutinilla pa una guarreria en SC5 y pa dibujar unas pruebas de graficos en SC2 pa pasar el rato. Hasta ahora que han venido a tocarme las bolas  >:(

Bueno, bueno, seguid :)

¿SC5?, ¿pero eso no es MSX2?,.....¡sacrílego! :spank:

Tambien tiene derecho  :'(  Pero tambien habra MSX1, tranquis.  ;D

Desde luego que tiene derecho. Es más, yo creo que habrá que ir empezando a mirar con buenos ojos al MSX2 para intentar hacer juegos que aprovechen sus capacidades. Tenemos unos ordenadores muy infrautilizados, ¡hay que darles toda la caña que se pueda!

Ánimo MsxKun!

Eres odioso ;D

Me sumo al anatema: sacrílego.  ;)

¿Dónde iremos a parar? Paletas, muchos colores, un color independiente por cada píxel... ¿Dónde queda la emoción de ver si se pueden hacer las cosas o no?

El tema está en subir las miras. Para el MSX2 y superiores yo empezaría a fijarme en juegos de Amiga y SNES... seguro que estrujando los chips se puede hacer algo interesante :D

Joder, yo voy al revés. Partiendo de un ZX80 ahora intento llegar al nivel de Spectrum ;D

Buen, tan sólo para informar que los problemas han desaparecido gracias a inicializar la ram. Una vez más, gracias por los consejos. ¡Ahora a seguir! ;)

Eso es lo que tiene el lado oscuro de la fuerza, que de vez en cuando hay que reinicializarlo un poco ;D

El ajjjjqueroso del Palpatine, mira que no añadirme un botón de reset ;D