Saludos Armando. Lo que no entiendas solo tienes que plantearlo y se te explica de otra manera.
Hola Germán, pues nada, vamos a ver si nos aclaramos.
Que fundamentalmente creo que te interesa más a ti, para ver si podemos solucionar el problemilla de tu programa.
Pero es en tu ordenador, y no dices que tipo es, ni a que frecuencia de pantalla va, ni nada. ¿En que momento se produce la corrupción del gráfico?, ¿en todo momento?
No. Se produce en el juego en si mismo. El pintado la parte de juego para ser más exactos, es la parte más afectada. Cuando entras en el juego muchos tiles aparecen en negro. Y cuando juegas el scroll no se pinta bien.
El title, con su scroll de letras, el logo ... todo eso funciona correctamente.
¿Qué modelo? Pues hombre, es un MSX1, y eso te lo he dicho ya varias veces, creo que debería de sobrar, puesto que, si me ciño a lo que quieres que me ciña (las bases del concurso) el aplicativo debe de funcionar en un MSX1 con 16k de Ram, y no funciona.
Pero vamos, ya que te veo amante de datos, que son indiferentes pues estoy seguro que fallará en todos los MSX1 (menos en el SVI738 que lleva el 9938 y ahí si funcionará), es un Sony HB20P. 64k de Ram, 16k Vram.
¿Y tu solo has llegado a esa conclusión?
. Bromas aparte, esto ya se sabía antes de que tu comentaras nada.
Lo cual nos lleva a que sigues haciendo algo MAL. Si con BIOS que ahora los dos hemos llegado a la conclusión de que no falla, falla, es que el problema es del programa.
Pués no, ya que en su momento en cada render se guardaban y recuperaban los valores de los registros, por si era eso que dices, se desactivaban las interrupciones, etc, pero no.
No, aquí es donde tu no me has entendido, aunque seguramente, viendo nuestros post, parece ser que no nos entendemos muy bien.
Me refiero a escribir en los puertos del VDP con las interrupciones activas. También es cierto que pudiese ser algún registro que no salves y te destroce todo, pero si el problema fuese ese, también pasaría en MSX2 y superior, y no pasa.
Al igual que también debería de pasar el problema en MSX2 o superior si fuese eso, pero es algo que nunca puedo saber a ciencia cierta.
Debes de mirar el código antes de emitir opiniones que al final son equivocadas, como lo de las pausas. Se implementó pausas después y antes del render y no solucionaba nada. Por eso se realizó ese render específico que resuelve el problema. ¿Cual era ese otro error?
Hombre, claro que lo podría hacer. Pero a veces me sobra con ver una cosa para saber por donde vienen los problemas. Además si te miro el código y te doy la solución, la cosa pierde su gracia, que ya no podría meterme con tu programa.
Me interesa que falle, hombre.
(seguimos con las bromas claro está
)
Te explico, si llegue a esa primera conclusión es porque YO mismo la he cagado pero MUCHO con eso. Estaba demasiado acostumbrado a que en MSX2 funcionan unas cosas que en MSX1 *no* funcionan. Y como me pasó y el problema era exactamente igual, pues emití mi juicio.
Pero bueno, ahora que lo dices ... así hablando he caído en una cosa.
¿Qué entiendes tu por "pausas" entre escrituras en el VDP? Es que igual está aquí el problema.
Un OTIR es un problemón. Según el TH del VDP esto te puede ir bien, si haces ese otir cuando la pantalla esta desactivada. Pero con la pantalla activa y fuera de VBL es un fallo seguro de corrupción.
Un OUTI, 3 cuartos de lo mismo. Tiene el mismo problema. Hace un tiempo hice un cálculo estimado simple para ver una rutina que me funcionase correctamente en todos los casos, sin preoucparme de si estaba o no en la VBL o tenía activa la pantalla.
Más o menos, así a ojímetro, calcule unos 12 o 16 ciclos entre escritura y escritura.
Resumiendo, si quiero transferir con outi (pues otir ya está descartado totalmente), lo hago así, que funciona correctamente (hablando de transferencias MASIVAS).
di
[inicialiacion]
bucle:
outi
jr nz,bucle
Un jr nz, sobra para que todo funcione. Si hablamos de pausa entre OUT y OUT, la cosa se va a unos 3 nops entre uno y otro.
Y asi te aseguro, comprobadísimo que no pierdes datos.
Bien, Robsy habla de efectividad y eficiencia en la programación, pero él mismo se contradice haciendo un agravio comparativo con otra aplicación, ya que esa aplicación esta desarrollada en un lenguaje compilado, e insisto esto no debe presentar ningún inconveniente, pero según el criterio de Robsy ¿es eficiente?. Ademas, ¿quien dice que toda la rom debe ser código?
La verdad no se cual es el agravio comparativo. Pero puestos a mirar efectividad de código, con lenguaje compilado podría hacer simil de tus 128k con los 128k del MH de Nerlaska. El usa C y esto es una cruz por el espacio en CODIGO que usa. Y sin embargo te ha metido un RPG en 128k así. Y tu has metido un simple motor de juego, de menos de 8k en ASM, en 128k, por lo tanto a ojos de un programador se ve clara la diferencia, y Robsy lo mira con esos ojos.
Independientemente de eso, todo da un poco igual. Es un dato tiene en cuenta un programador cuando hace un análisis de otro programa, es deformación profesional. A ojos de un jugador, todo eso da igual. Lo que importa es el juego, no el tamaño que ocupa.
Y sobre todo HOY en día, y con las bases del concurso en la mano, claro. Ahora bien, si tu trabajases en una empresa de videojuegos para MSX de hace unas décadas y quisieras sacar Skate tal como lo has hecho, te aseguro que te hubiesen denegado el proyecto. Gastar el hard de un megarom con lo CARO que era en la época cuando encima no está justificado, pues no era algo muy normal.
¿O es que me puedes comparar la cantidad de "juego" y variedad de un Usas, un Salamander o un Galious, Golvellius (sigo?) que son 128k, con tus 128k?
Y si, antes de que me digas lo mismo otra vez, tu juego es totalmente legal para con las bases del concurso. Todo esto es un detalle, un comentario y no afecta para nada.
Pués yo te lo explico, lo primero que se publica son las bases, y sorpersa! ahí puedes leer que se pueden implementar rom de 128k, y en ese momento es cuando deberías de hacer tus comentarios de como debe ser, y no cuando ya está publicada la aplicación.
Ains ... este punto me pierde. Creo que no nos entendemos. Yo te digo, como Edu, que los 128k no están justificados, tu me dices que lo podía haber dicho antes, y yo te digo que no soy vidente y no podía saber como iba a ser tu juego. Y ahora me vienes con que está en las reglas y lo tenía que haber dicho antes.
Creo que no nos entendemos German.
Yo hablaba como Edu, de tamaño 128k no justificado PARA TU JUEGO, no para el concurso.
Después dices que no entiendes las cosas. Eso era y es un ejemplo de posibles errores ya que tu solo depuras a nivel de sistema. Y estoy tranquilo, no sé si tu lo estas, ya que esos testers y que tu ya comentas no te lo van a detectar todo, y el error colateral es un ejemplo de lo que no te van a detectar.
No, no las entiendo, y pongo la mano en el juego que no soy el único que no se termina de aclarar con tus mensajes.
Ya comentamos que a veces la comunicación telemática da lugar a maltentendidos y es lo que intento solventar.
A ver, no se como explicarte que yo depuro a nivel DE TODO. Y cuando el programa funciona correctamente y no tiene errores colaterales, gracias a mis testers, es cuando le hago el test de máquina para ASEGURARME que va en todas las plataformas compatibles MSX para los cuales el programa ha sido desarrollado.
¿Que parte no entiendes de eso?
Además, en este punto, no es tu caso, puesto que me he atrevido a mirar un poco tu código y veo qu ehaces alguna que otra burrada para seleccionar los slots del juego, ya que ignoras completamente el subslot. Hablo un poco sin poder probarlo, pero me huele que tu programa insertado en un cartucho y en un expansor de slots NO funcionará.
¿Ves? No es un error colateral, es un error de programa y ha de ser testeado en muchas máquinas para ver que pasa eso. La diferencia entre mi código y el tuyo es que yo YA tengo eso en cuenta y no tengo que hacer ese test AUNQUE LO HAGO.
Pués lo que te estoy diciendo desde hace algún post!!!!. Ya te lo he comentado antes, tu depuras a nivel de sistema, o llámalo arquitectura, hardware o como quieras. Y no es correcto partir de la base de que tu programa está bien, ya que se debe hacer la aplicación en función a la arquitectura, por ejemplo.
A ver, aquí son habas contadas, y no hay programa en funcion de NADA. Tu debes de hacer un programa que vaya en MSX con 16k de Ram y 16k de Vram. Y PUNTO.
Y ese programa te irá si lo haces correctamente en TODOS los MSX. No hay más vuelta de hoja German.
Se agradece. Me parece que el programa es funcional como está, si tu dices que en tu ordenador no va, se podría observar donde está el problema.
Perdona tu programa NO es funcional, y te lo puedo demostrar cuando quieras. Creo que te estás confundiendo mucho conmigo German, y con Edu y con los demás. Mi única intención es que puedas arreglar ese problema y no lo arrastres para tus futuras "aplicaciones". Aquí nadie te ha dicho las cosas para mal. Pero si tu sigues en tus 13 que todo va bien, pues adelante. No podré jugar a tus aplicaciones en mi MSX. Creo que no es eso lo que buscas, no?
El error en MSX1 no me lo invento, no saco nada con inventármelo hombre.
Y además, precisamente estaba en mi casa Imanok anteayer cuando lo probamos y lo vio con sus propios ojos.
Repito: Sigo AQUI para que me mandes las pruebas que hagan falta, para ayudarte con las rutinas o lo que sea.
