|
burguera
Visitante
|
 |
« Respuesta #30 : 03 de Febrero de 2009, 04:28:06 pm » |
|
Respecto a la compatibilidad, no es la primera vez que sale el tema y creo que es muy importante. Es parte de lo que da seriedad y calidad a la Dev: que funcione en todos los MSX. No creo que sea cuestión de si ha habido tiempo para comprobarlo, es algo "obligatorio".
Otro tema distinto es el que parece ser el caso de La Corona Encantada. Ojo, aún no lo he probado en mi MSX, sólo en emulador. Pero la idea es que, al ser una ROM, funcione como cartucho en cualquier MSX. Si el problema es que no carga con un cargador de ROMs por cuestiones del cargador, obviamente no es algo que deba achacarse al juego.
|
|
|
|
|
En línea
|
|
|
|
|
mesiasmsx
|
|
« Respuesta #31 : 04 de Febrero de 2009, 02:47:12 pm » |
|
Claro, mesiasmsx, una vez que compras un cartucho, éste debe correr en cualquier modelo. Pero para la dev, si por falta de tiempo no se ha podido probar en todos los modelos, espero que al menos funcione en un MSX1; preferiría que en todos, claro.
Ya, una vez que pagas por un cartucho, es otro asunto. Ahí debe haber más seriedad.
Yo estuve buscando betatesters la última semana y no me fue fácil encontrar alguno... vamos, que nadie, por un motivo u otro, pudo hacerlo -lo comprendo, ya me podía haber decidido antes a entrar en la dev. Yo lo probé en un 8280 y funcionaba. No pude probarlo en un MSX1 japonés, ni turbo r, aunque los tengo, por motivos de cables/tele.
Sigo pensando que aunque no compre alguien el cartucho,eso va a gusto de cada uno,si un juego es libre,debe funcionar igualmente en cualquier MSX pro que alguien puede no tener una megaflash o no. Yo personalmente si me gusta un juego lo compro pero puede haber alguien y aquí no entro a valorar que no pueda o quiera como he dicho comprarlo. De ahi de que todos los juegos que se presenten al DEV deberian funcionar en cualquier generación. Respecto a los betatesters yo me presente voluntario en el hilo creo de quedan menos de dos semanas y no recibi respuesta alguna de nadie, supongo que serian las prisas. Tengo el TR y el ESE System para futuras ocasiones si alguien va apurado. |
|
|
|
|
En línea
|
|
|
|
|
mesiasmsx
|
|
« Respuesta #32 : 04 de Febrero de 2009, 02:55:37 pm » |
|
Otro tema distinto es el que parece ser el caso de La Corona Encantada. Ojo, aún no lo he probado en mi MSX, sólo en emulador. Pero la idea es que, al ser una ROM, funcione como cartucho en cualquier MSX. Si el problema es que no carga con un cargador de ROMs por cuestiones del cargador, obviamente no es algo que deba achacarse al juego.
Bastante de acuerdo contigo, pero y si no sale en cartucho nunca el juego y alguien no tiene megaflash? No se si los cargadores fastidian a un juego a la hora de cargar por que se pisan,que lo expliquen los programadores asi nos ilustran. |
|
|
|
|
En línea
|
|
|
|
|
mesiasmsx
|
|
« Respuesta #33 : 04 de Febrero de 2009, 02:58:34 pm » |
|
Pero es que yo no hago el juego para que sea compatible con cargadores de disco. Si alguna otra cosa enchufada al MSX pisa algo de RAM del juego, no creo que sea problema del juego en si. ¿O si lo es? (que algún experto me lo aclare, por favor, porque ya estoy un poco flipado con eso de que "no funciona")
Entiendo,funciona perfectamente en la megaflash (lo he probado) que es realmente lo más importante de todo, auqnue seria bueno que ne los cargadores de MSX pudieras jugar tb si no tienes megaflash como algunos les pasara. No se que dificultades entraña programar el juego y que luego funcione en los cargadores. Si tu lo sabes lo podrias explicar para que sepamos más del asunto. |
|
|
|
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #34 : 04 de Febrero de 2009, 03:16:18 pm » |
|
El problema no suelen ser los cargadores, sino que la RAM que emplea el sistema de disco puede ser sobrescrita por las variables del juego, a lo que no suelen reaccionar bien los dispositivos. Por eso, una vez más, queda acreditado que lo mejor del mundo mundial es cargarlo todo desde cinta  El mejor ejemplo es el juego "Vampire" de Manhattan Transfer. Como el programa en BASIC ocupa casi 28 KB no hay forma de que funcione en un MSX con disco. Debe cargarse, por lo tanto, desde cinta guste o no. Y es un programa compatible 100% con todos los MSX, porque está desarrollado en BASIC puro y duro. Pero para jugarlo en un Turbo-R no hay más remedio que teclearlo a mano En principio, estas dificultades de solapamiento podrían resolverse, pero no siempre es fácil conseguirlo. Y, de nuevo, de estos aspectos debería encargarse el programa cargador, no la propia ROM. |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #35 : 04 de Febrero de 2009, 03:23:01 pm » |
|
No se que dificultades entraña programar el juego y que luego funcione en los cargadores. Si tu lo sabes lo podrias explicar para que sepamos más del asunto. Si me permites, puedo intentar ilustrar este problema. Todo el problema gira en torno a la BIOS. Si el juego no prescinde de la BIOS y utiliza el modo de interrupciones 1 (el clásico), la BIOS estará siempre haciendo su trabajo una vez cada blanqueo vertical. Este trabajo consiste en una serie de acciones que provocan que la zona superior de memoria (que es la zona de trabajo de la BIOS) se vea modificada. El tema es que un cartucho ROM supone (y con bastante acierto, he de decir) que él tiene el control total del MSX, cediendo en ocasiones parte del control a la BIOS. Pero si hay algún periférico que reserve memoria adicional, posiblemente también se haya enganchado en la zona de ganchos, por lo que sus rutinas de control también serían ejecutadas en la interrupción, modificándose su zona de memoria. Contra esto poco hay que se pueda hacer. Dos cosas funcionan con total seguridad: -Roms de 48K que mantienen visible su página 0. Si se opta por este formato de juego hemos de prescindir TOTALMENTE de la BIOS, por lo que hemos de colocar en el lugar adecuado la rutina de gestión de interrupciones del juego. Con esta opción tenemos libre la memoria RAM hasta $FFFE (mejor no tocar $FFFF por razones obvias). -Se puede usar el modo IM2 (lo que ha hecho Dioniso en su juego) y así tener el control absoluto de las interrupciones. El problema es que es algo abstruso (aunque una vez resuelto es muy cómodo) y que se come 257 bytes en una tabla. Y luego otra opción que consiste en enganchar la rutina de interrupciones del juego en $FD9A y leer el registro de estado del VDP, esto limpia el bit de interrupción y ya no se saltaría al siguiente gancho ni se seguiría ejecutando la rutina de gestión de interrupciones de la BIOS al volver. No conozco el funcionamiento de la BIOS lo suficiente como para asegurar que esta opción funcione correctamente, pero creo que sí. Sólo sería necesario reservar los tres bytes situados en $FD9A - $FD9C para la BIOS, pudiendo disponer del resto de la ram (hasta $FFFE, no lo olvidemos) a nuestro antojo. Por cierto, en la sección de snippets publiqué hace tiempo uno para hacer esto. |
|
|
|
|
En línea
|
|
|
|
utopian
Karoshi Newbie
Mensajes: 42
|
|
« Respuesta #36 : 04 de Febrero de 2009, 09:47:13 pm » |
|
Yo me encontré en su día con un problema adicional, que aunque en mi caso pude resolver no sé si dará siempre problemas. Es de perogrullo, pero al ejecutar la ROM con un cargador estás corriendo el juego desde RAM, con lo que algunas cosas que puedes asumir desde la ROM no son ciertas. Por ejemplo, la rutina de detección del SCC que usábamos en BeTiled! escribía valores en ciertas zonas para buscar el SCC en los slots. Si tienes el juego en ROM, no hay problema, porque una escritura en ROM es ignorada y punto. Si un cargador te lo pone en RAM, date por j*d*d*, porque vas a machacar parte de tu propio código  . En nuestro caso pude arreglarlo, pero dependiendo de cómo sea cada juego habrá cosas que no vas a tener en cuenta, y que pueden hacer que casque al cargarlo en RAM. Supongo que generalmente es posible hacerlo "bien" y que sea compatible, pero no tengo suficiente experiencia a priori para garantizarlo. |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #37 : 08 de Febrero de 2009, 10:24:08 pm » |
|
Pues yo ya me he terminado el juego... en el modo normal  Muy chulo el desarrollo y la verdad es que cuando le pillas el tranquillo no es tan difícil como parece y en menos de dos horas desde que empecé a jugar en serio ví el final. Ahora me toca terminarlo en otro modo de juego al que tienes acceso cuando ya te lo has terminado una vez  Lo dicho, que al ataque con el juego!! |
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #38 : 09 de Febrero de 2009, 08:22:44 am » |
|
Pues yo ya me he terminado el juego... en el modo normal Ese SapphiRe!! Viva, si es que eres un hacha!  Muy chulo el desarrollo y la verdad es que cuando le pillas el tranquillo no es tan difícil como parece y en menos de dos horas desde que empecé a jugar en serio ví el final.
Si es que es lo de siempre en estos juegos. Tratar de conocer lo mejor posible el mapeado y determinar la ruta más óptima para poderte terminar el juego dentro del tiempo. Kepa se lo terminó también tras 3 horas de ponerse en serio: por esa razón incorporé el modo "difícil" Ahora me toca terminarlo en otro modo de juego al que tienes acceso cuando ya te lo has terminado una vez Además, así verías el final completo Lo dicho, que al ataque con el juego!!
Pues nada, ya van dos que se lo pasan! (aunque a SapphiRe todavía le queda un modo de juego). Esto SI es lo que mola, saber que alguien (al menos 2, de momento), han pasado un buen rato picados con el juego...   . Sólo me queda una cosa por decir: "Thank you for playing this game!" ¿Quién será el siguiente?, yay! |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
Ramones
Visitante
|
|
« Respuesta #39 : 09 de Febrero de 2009, 01:18:46 pm » |
|
En nuestro caso pude arreglarlo, pero dependiendo de cómo sea cada juego habrá cosas que no vas a tener en cuenta, y que pueden hacer que casque al cargarlo en RAM. Supongo que generalmente es posible hacerlo "bien" y que sea compatible, pero no tengo suficiente experiencia a priori para garantizarlo.
Tu problema, y supongo que sería así como lo arreglaste, es tan sencillo como saber tu slot/subslot y no pasárselo a la rutina detectora de SCC. De esa manera no te machachas nada. Machacar la Rom es una técnica habitual de protección para evitar, precisamente, que nadie juegue en Ram. Luego hay casos donde el juego jamás podrá funcionar en RAM. Estos casos requieren demasiada complejidad en el código, hacerlo adrede vamos. Por poner un ejemplo en el I Need Speed se busca memoria, para ver si se tienen 32k. No es que la búsqueda esté bien hecha, pues se asume que cuando arranca el ROM hay RAM puesta en la página 2. Esto es un error, pues puede haber CUALQUIER cosa, ya que si otro Rom se ha ejecutado antes, ha podido mover las páginas. Y aun voy más lejos, la BIOS no te garantiza que exista Ram ahí. Hay que buscarla. Y lo único que hace es escribir en 08000h y 09000h comparar lo escrito y ver si es Ram. Pero volviendo al tema de ejecutar en RAM, este juego, como es lógico no podrá funcionar en RAM. Busca Ram, y la usa y si el juego está ya en RAM es la misma Ram que encuentra, por eso se machaca. No esta mal. Repito, es lo lógico. Pero es lo lógico si el juego se va a meter en un cartucho, o se ejecuta desde un ROM. En caso contrario, para poder ejecutar desde un ODO o similar, habría que preparar el código. Primero buscando la RAM en todos los slots/subslots y segundo evitando que sea el mismo slot/subslot del juego. Ante esto solo queda una duda. ¿El concurso exige que los juegos puedan ser jugados sin necesidad de hardware extra o bien en su versión final? Creo que queda más claro que lo que exige el concurso es una ROM funcionar. Y una ROM es una cosa que no se puede escribir. Todo esto me lleva a la siguiente cuestión... si, por ejemplo, en el caso del I need Speed solo se puede grabar en cartucho, o en una Flash de última generación de Pazos (que soporta 48k)... ¿cómo testean los jueces/equipo del dev si la entrada es correcta? ¿Con un emulador? Esto me parece un poco feo, no creeis? |
|
|
|
|
En línea
|
|
|
|
|
nerlaska
|
|
« Respuesta #40 : 09 de Febrero de 2009, 05:05:23 pm » |
|
Entonces, cuando yo arranco una ROM, en teoría, no debo dar por hecho que desde la 0xC000 hasta la 0xFFFF voy a encontrar RAM? Es por tenerlo claro. Y con respecto a lo que dice Armando .. pues yo creo que los jueces deberian jugar con MSX reales a los juegos .. más que nada para verificar 100% que el juego se completa con un MSX real. Y de hecho, debería jugarse y pasarse los juegos en MSX1, 2, 2+ y TR. Mola el rollo puritano  |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #41 : 09 de Febrero de 2009, 05:10:21 pm » |
|
Entonces, cuando yo arranco una ROM, en teoría, no debo dar por hecho que desde la 0xC000 hasta la 0xFFFF voy a encontrar RAM? Deberías darlo por hecho si el ordenador tiene, al menos, 16k. Si tuviera menos de 16k (es decir, 8k) sólo habría RAM desde $E000 hasta $FFFF. Saludos -- Sph. |
|
|
|
|
En línea
|
|
|
|
|
Ramones
Visitante
|
|
« Respuesta #42 : 09 de Febrero de 2009, 06:03:48 pm » |
|
Entonces, cuando yo arranco una ROM, en teoría, no debo dar por hecho que desde la 0xC000 hasta la 0xFFFF voy a encontrar RAM?
Estamos en el hilo incorrecto, por lo que sugiero a Jon que mueva estos mensajes a donde crea conveniente. Respondiendo a tu pregunta, si y no. Si no hubiese memoria en esa zona el MSX no arrancaría. xD PEEERO, NO puedes suponer que hay memoria de 0xC000 a 0xFFFF, si no que lo ÚNICO que sabes seguro es que hay memoria de 0xE000 a 0xFFFF, es decir 8k. Es por tenerlo claro.
Para tenerlo claro a partir de ese momento entra en juego el programador. Si quieres usar 16k, y quieres dar algún mensaje si se conecta en un ordenador de 8k (cosa que no hace ni hacía nadie, porque ya viene en la caja puesto y ya está), tienes que mirar si entre 0xC000 y 0xDFFF hay Ram. Y entonces tendrás 16k de Ram. A lo que yo me referíacon el I Need Speed, no era a eso. Ellos ya asumen 16k, porque sus especificaciones dicen 16 o 32k. Para saber si tienen 32k es cuando lo buscan, como decía antes. Pero no está fino del todo, aunque no está mal del todo. En estos momentos podría adjuntar todo mi tutorial de buscar memoria, ejemplos y rutinas (hechas por mi pero sacadas del TH, BIOS y de una DISKROM standard, vamos, más standard imposible), pero quiero aprovechar para hacer PROPAGANDA. Creo que fue en la última Call MSX donde expliqué todo esto. Así que ya sabéis, comprad la revista. Y con respecto a lo que dice Armando .. pues yo creo que los jueces deberian jugar con MSX reales a los juegos .. más que nada para verificar 100% que el juego se completa con un MSX real. Y de hecho, debería jugarse y pasarse los juegos en MSX1, 2, 2+ y TR. Mola el rollo puritano Es que creo que te sobra hasta el *deberían*. Dado que el concurso es de JUEGOS DE MSX. No de juegos que corren sobre un emulador de MSX en otro ordenador. Pero bueno, que esto es como una cruzada de Armando de toda la vida contra todo. No hay Dev donde no exista algo mal. Pero incluso en juegos fuera de Dev también pasa. POr ejemplo el último de Wolf del como se llamase Jones ese, es para 64k de Ram, pero en equipos con 32k y 32k en otro slot de Ram no funciona. Además ni busca ni nada, asume. PEEEERO, ¿se puede achacar? En el caso de Wolf, no. Pues como es un juego GRATUITO no nos podemos quejar. En el caso del Dev, es mitad y mitad. Son juegos gratuitos, no se pagan, no hay queja, excepto las exigencias de los jueces y organizadores. |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #43 : 09 de Febrero de 2009, 07:10:10 pm » |
|
Para tenerlo claro a partir de ese momento entra en juego el programador. Si quieres usar 16k, y quieres dar algún mensaje si se conecta en un ordenador de 8k (cosa que no hace ni hacía nadie, porque ya viene en la caja puesto y ya está), tienes que mirar si entre 0xC000 y 0xDFFF hay Ram. Y entonces tendrás 16k de Ram. Eeemmm... el QBIQS lo hace... comprueba si en $C000 hay RAM y si no la hay muestra un mensajito en SC0 y bloquea el MSX. |
|
|
|
« Última modificación: 09 de Febrero de 2009, 07:14:32 pm por SapphiRe »
|
En línea
|
|
|
|
|
WYZ
Visitante
|
|
« Respuesta #44 : 09 de Febrero de 2009, 11:16:55 pm » |
|
Todo esto me lleva a la siguiente cuestión... si, por ejemplo, en el caso del I need Speed solo se puede grabar en cartucho, o en una Flash de última generación de Pazos (que soporta 48k)... ¿cómo testean los jueces/equipo del dev si la entrada es correcta? ¿Con un emulador? Esto me parece un poco feo, no creeis?
Esa cuestión viene de porque se eligió el formato ROM ¿?, muy cómodo para algunas cosas pero que tiene su pequeñas pegas. Si las normas DEV dicen que el formato debe ser este ¿porque luego deberían quejarse los jueces que, en principio, deben estar de acuerdo con las normas? Si se llega a un punto en el que, como en algún caso, el juego no fona en la RAM de un MSX... pues la cosa está clara: O se cambia el formato o se añade la siguiente norma " Ademas deberá rular en RAM"....Al fin y al cabo si que es feo que un juego se valore en un emulador. |
|
|
|
|
En línea
|
|
|
|
|
