Karoshi MSX Community

Pues nada, aquí tenéis un nuevo Karoshi para devorar! Desde Night Driver (y más tarde, G-Monkey), no habíamos podido sacar nada, pero bueno, poco a poco van saliendo.

La Corona Encantada es un proyecto que le tenía ganas: siempre he querido hacer un tributo a los juegos de Dinamic y Topo de la época, y éste es mi intento, un juego de plataformas de corte medieval que espero que os guste. Hay quien se queja de la dificultad y quien se lo ha pasado en tres horas... digamos que es un juego como los de entonces, donde el conocimiento del control y del mapeado es crucial para podértelo pasar. Lo dicho, a disfrutarlo, espero que os guste ;)

Por cierto, estoy preparando la conversión a spectrum y una versión MSXera (la que pienso hacer en edición física) donde todo tendrá más color y más pinta MSX (aunque se podrá elegir el "modo legado" para jugar también al juego con el look spectrumero, que era lo que se buscaba).

Venga, ánimo a todos! Ahora le tengo que hacer unas cosillas al robsy para su entrada y testearle a dioniso, awww!!!  :)
http://msxdev.msxblue.com

Ya me había dado cuenta  :D El juego está genial, tiene un feeling retro guapísimo: un Camelot Warriors pero muchísimo mejor. Me ha gustado bastante. Enhorabuena a ti y los que han colaborado en el proyecto.

¡Me entanta! A mi me recuerda especialmente al Hundra por sus escenarios y la suavidad de movimientos FX Syncro Sprites.

Enhorabuena, gracias  :)

Si que mola si. Enhorabuena. Va muy fluido, mucho mejor que muchos juegos antiguos. Es dificilillo porque siempre hay el que te toca, pero con practica se puede llegar mas lejos. En el proximo update mas msxero como dices a ver si nos deleiteas con una paleta msx2 como minimo.  ::)

Ostras, lo he pasado al Turbo R y no me rula, se cuelga al pulsar para jugar. Lo he probado con el Rima y el Odo. Tambien he hecho chgcpu y lo mismo. Que alguien mas lo pruebe.

Con el I need speed tres cuartos de lo mismo, se cuelga al pulsar el 0. El Danger Tower me va perfecto.

Se intenta que los juegos corran en todos los modelos, pero si se te ocurre meterte en MSX extremo puede pasar cualquier cosa. No me extrañaría que mi entrada tampoco furrulase en un Turbo gRande, aunque utilicé el snippet de Dioniso en este (http://msxgamesbox.com/karoshi/index.php?topic=668.0) thread  ;D

Lo más importante para mí, y esto es personal, es que los juegos de la dev corran, al menos, en un MSX. Después ya se arreglarán cosillas para que funcionen en todos.

La corona encantada no me va en el GT con odo, pero si funciona con execrom.

No olvidéis que los juegos están pensados para ser ejecutados desde cartucho...

Pues no se, la verdad. Es un rom sencillito de 32kb que no hace ninguna maldad en especial, salvo consumir mucha RAM. Cuando vuelva a casa a la tarde miraré a ver para arreglar lo que haya mal, de haberlo.

Por cierto Dioniso, al final no he podido testear en el msx1 el juego, me falta un cable... Alguien que quiera ayudarle para la causa??

No te preocupes, no pasa nada.

Joder, Jon!
Te has salido!!!! :D

Independientemente del look spectrumero, que como apuntas va a ser convertido (lo cual hace que se me ponga tiesa), está cojonudo. Gráficos, movimientos, música (beyker&wyzinho?), ... Parece un juego de dinamic, en serio te lo digo. Chapeau, me quito el sombrero. :-)

Habla con artaburu, que esto merece una versión cepecera!!!!

Por cierto, quiero mi premio por haberme tragado el texto de introducción enteritoooo!!! :lol:

Abracicos y suerte en el concurso! ;-)

(y un día de estos, hablaremos tu y yo del subacuatic...)

Por cierto, que no te he ficho que está de puta madre! (por cierto, la musica del Genghs muy guapa también!!!

Pues gracias, hombre. Aunque sin música... Y, la verdad, estoy cansado... Creo que lo voy a enviar así. No puedo hacer una canción 1bit en un segundo. Eah! La versión se queda como te la envié (Pero que conste que a este juego le debo la música de la intro).

Con este juego evocas a los grandes de antaño. Gracias Jon & Cia y suerte.

Saludos.

Vale, pero mándamela al mail del concurso y con un manual en txt o algo  ;) ;) ;)

Yo, chicos, he probado el juego en MSXes reales desde cartucho (que es la buena), y funciona a la perfección. Tal vez, al tirar de mucha RAM (mas de 12KB), al no ser ejecutado directamente desde ROM, el juego pisa algún tipo de "algo" en RAM que deja el cargador de ROMs (es un suponer, la verdad es que, de cargadores de ROMs no tengo mucha idea)... lo he cargado también en MSX1 con un WAV creado por el WaveR, y también me tira... no se, puede que sea lo mismo que pasa para el I Need Speed, que incluso comentan que son preferibles 32KB RAM.

De cualquier forma, el cartucho físico funciona OK y eso es lo importante para el concurso: si luego hay que hacer algun tipo de versión para disco o así, pues ya se hará ;)

Sacaré tiempo para ver si me gusta y cuanto tardo en pasarmelo  :P ;)

Jon,

Probé el juego y sí se cuelga si tienes un IDE pinchado, por ejemplo. Incluso desde la MegaFlash. Así que ésa debe ser la razón por la que no funciona con ODOs y similares. Supongo que al ir a buscar antes el arranque del slot 1 y luego el del 2, de alguna manera se machaca algo en la página 3 (o se inicializa mal el tema de la disketera).

Configuración rápida con la que falla tal y como decía guantxip:

1. Slot 1: IDE+CF
2. Slot 2: MegaFlash

Un saludo y espero que sirva!

Enhorabuena por un nuevo karoshi-proyecto terminado :) (y más aún conociendo tu nueva situación familiar, que imagino no te ha dejado demasiado tiempo libre).

Se nota que has mejorado el motor del Infinity ;)... la verdad es que, en cuanto a jugabilida, este me gusta mucho más que el primero y detalles como lo del cambio de cámara al tocar un 'switch' están muy bien.


No acabo de comprender el motivo de tu elección en cuanto a lo de buscar el look spectrum (con todo lo que hemos renegado siempre de dichas conversiones), pero vamos está claro que lo has conseguido. Por mi parte, espero ansiosamente ver la versión con gráficos MSX 'de verdad'  ;)

Te auguro, si no el primer premio, el segundo... ya lo verás.

Se me olvidaba esto!


Yo tengo la SDMMC de Padial en el slot 1 y me pasa lo mismo. Para que funcione bien en la megaflash, tengo que dejar pulsada la tecla GRAPH para que no haga caso a la SDMMC, si no se cuelga el juego.


Me mola mazo que llames a tu hermano por el nick!  ;D ;D ;D

Jon, mi primera impresión del juego es muy buena. Imagino que has aprovechado y ampliado el motor del Infinity. Y el resultado me parece un juego coherente: todo muy "ochentero" y muy "europero-speccy".  A mi me encanta la estética speccy. Tengo que jugarlo más, pero de momento me gusta, como ya me gustó Infinity.

La única pega es, en mi opinión, esa estética excesivamente speccy. El Infinity tenía una estética tipo "como tendrían que haber sido los juegos europeos para MSX". De hecho, trasteando con el Meisei, veo que has tenido que currarte los sprites por hard para que tengan ese tono speccy.

Aún así, en el fondo es sólo una cuestión gráfica, el juego me parece (tras esta primera impresión) coherente y divertido. Voy a jugarlo más.

Debo decir que, tras jugar a este juego y al Danger Tower me han entrado renovadas ganas de programas. Lástima que tenga poco tiempo. 8(

Efectivamente, el control del personaje y las colisiones parten del motor que me curré para la versión MSX de Infinity. Aparte de mejorar el control y la gestión de animaciones del personaje, para que tenga más frames que en Infinity, reprogramé el sistema de enemigos para que me permitiera tener muchos más y con más frames, e hice toda la gestión de mapeados "dinámicos", incluyendo las palancas, para que se permitiera más interacción con el mapeado. Luego me pareció interesante que se vieran animadas las cosas que ocurrían al pulsar las palancas, así que me cree un pequeño sistema de animación por comandos que me permitía fugar a cualquier pantalla, modificar tantos bloques como quisiera, y después salir, para hacer que el juego fuera un poco más amplio que tan solo un mapeado y listo. Además, también le he añadido el factor "tiempo" para complicar un poco las cosas, y un modo de juego extra, al que se accede a través de un cheat (primero tendrás que acabarte el juego, jeje). De cualquier forma, y aunque le he dedicado bastante a la programación, lo que más me ha costado es crear un mapeado interesante y que tenga sentido para que le vaya picando a la gente a ir descubirendo más zonas y más monedas.




Pues yo creo que el motivo está claro. Aunque ese tipo de juegos no aprovechen al 100% el MSX, anda que no hemos jugado (y disfrutado) a juegos como Phantomas 2, Nonamed o Hundra, por citarte unos pocos. Al final la verdad es que yo me muevo por la nostalgia ;), y he jugado tantos Konamis como Dinamics o Topos y, no se, me apetecía hacer un algo con ese estilo tan caracterísitico. Me alegro de haberlo conseguido, por lo que veo ;)



Ya te digo, mi hermano se lo pasó en 3 horas, y luego hay mucha gente que dice que es muy dificil. Es lo de siempre en estos juegos, conocer el mapeado y los controles. Con eso no tardarás en terminartelo, seguro ;)



Efectivamente, ese puede ser el problema. El juego es muy exigente en cuanto a RAM, me quedo muy cerca de las variables del sistema, pero calculado para no pisarlas nunca con bastantes bytes de seguridad. El caso es que si tienes enchufado un algo que utiliza esa zona alta de RAM, pues el juego, que necesita esa RAM, lo pisará y no funcionará. Esos son los requerimientos, 16KB de RAM. Si hay algo externo que utiliza más RAM, pues obviamente el juego no funcionará. De cualquier forma, yo lo he probado en mi MSX2 con EXECROM y funciona a la perfección, incluso el ending. Eso si, sin enchufarle nada adicional ;)

El SHIFT es siempre vuestro amigo ;D

Es lo que pienso yo,me gusta el juego,pero hubiera preferido al menos un paleta pura MSX1, el aire Speccy no acaba de gustarme,un asi es un muy buen juego.

Respeto pero no comparto, lo importante,y por más que se habla parece que cae en saco roto, es que funcione en todas las generaciones de MSx,sino de que vale hacer un juego si en tu modelo no vas a poder jugar. No me parece correcto, deberia todo programador molestarse en que su juego funcione en cualquier generación de MSX. No sera por falta de betatesters. Y si sacan "La corona encantada" en cartucho y me lo compro y no puedo juegor por que un Turbo R ya es algo extremo? Por favor, deberian ser más cuidadosos a la hora de programar.

Pero, no entiendo... ¿es que acaso "La Corona Encantada" no funciona desde cartucho en algún MSX?

Perdona viejo que haya puesto tu juego como ejemplo al uso. Pero esto es una realidad que ha ocurrido en todos o mayoria de los dev y pienso que se deberia atajar. Evidentemente guantxip tiene problemas en su TR y seguro que yo tb. Otra cosa es que funcione en versión cartucho que seguro y deseo que sí,pero estas cosas me dan cierta grima. Respeto y valoro a todo aquel que desarrolla para MSX, y más con las ocupaciones que tiene todo el mundo que ha de sacar su tiempo libre que podria estar tumbado en el sofa o con la parienta en la cama,pero lo uno no quita lo otro para que se hagan las cosas bien hechas.Hablo en general,y muchos de vosotros os estrujais los sesos por hacerlas bien,pero ya te digo, veo alguna quie otra cosa que se repite,nada más.

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")

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.

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.

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.

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.

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.

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  ;D

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  ;D

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.

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.

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  :o.

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.

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 :P

Lo dicho, que al ataque con el juego!!

Ese SapphiRe!! Viva, si es que eres un hacha!  ;)



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" ;)



Además, así verías el final completo ;) ;)



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...  :D :'( :D. Sólo me queda una cosa por decir: "Thank you for playing this game!"  :D :D

¿Quién será el siguiente?, yay! ;)

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?

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 :)

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.

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.


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. :D Creo que fue en la última Call MSX donde expliqué todo esto. :) Así que ya sabéis, comprad la revista. :P


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.

:)

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.

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.

Yo no.... porque mis juegos van en 8k. :P

Panda de frikis ;D
Parecéis dos pescadores presumiendo de la pesca

Bueno, lo cierto es que ya llevaba la idea rondándome por la cabeza desde hace un par de años, cuando Salva y yo estábamos en mi casa después de una MadriSX & Retro (aún se llamaban así) y probábamos el Gradius II de PC-Engine en el emulador para la XBOX. Resulta que pusimos una tarjeta de CD inadecuada y salía una animación muy graciosa indicando que necesitábamos la tarjeta patatín...

Tened por seguro (y llamadme friki) que cuando haga un juego para MSX2, si se pincha en un MSX1 va a salir algo más elaborado que un simple mensajito ;D ;D ;D

A tenor de ésto, ya tuve una discusión con GuyveR800 y BiFi. Opinaban que el problema no eran los juegos en sí, que asumían (correctamente, por otro lado) que estaban en ROM, si no los cargadores, que tenían que ser más inteligentes.

Mi opinión es que tampoco cuesta tanto facilitar la labor de los cargadores y que el juego pueda funcionar en RAM sin problemas.

Como ellos. :D A ver, que tienen razón, claro que si. El juego HA de funcionar en su modo natural, es decir LA ROM. SOLO hay un problema, y es que eso no ocurre siempre.


En efecto, a veces cuesta poco, pero a veces es imposible, depende de como sea el programa.

En cualquier caso, sobre el modo "inteligente" de que un cargador de Ram funcione, hay muchos problemas, partiendo de la base de que el juego ROM no esté preparado. Enumero:

a) ¿Que hago si la Ram del MSX está en distintos slots/sublots? Los juegos ROM siempre funcionan en el mismo slot. En caso de ser un 32k o más se posicionará solito en donde arranque (el slot subslot), por lo que, o se tiene la Ram lineal o no va. ¿Cómo solucionan esto los inteligentes? :D Obviosamente, hay una solución, la explico al final.

b) El juego busca memoria porque la necesita. Imaginemos, de nuevo un 32k. Que necesita 32k de Ram, PARA LO QUE SEA. En el momento que encuentre memoria lo más fácil es que encuentre la memoria donde se está "emulando" el cartucho. ¿Cómo se soluciona esto? De nuevo solo hay una forma
 
c) Juegos de Basic: Emular un ROM de Basic es un infierno. Hay un caso especial donde no se puede emular bien desde RAM.

d) El juego se sobreescribe para evitar que vaya en Ram. ¿Cómo solucionamos esto? De nuevo con la única solución plausible.

Solución, como dije: Parchear el juego. El cargador "superinteligente" de Bifi y Patriek debe de tener una base de datos, hacer un  checksum para saber qué juego es y parchear las zonas conflictivas. Porque hacer algo GENERICO para esto es IMPOSIBLE.

Y además, es que solo hay que ver lo que hace Bifi: Prepara IPSs para que funcionen cno la flash de Padial de todos los juegos. Es lo más lógico y obvio, y está muy bien. Pero... ¿a que no hace un programa "inteligente" que haga eso por si solo en tiempo real cuando carga la Rom? No es que no se pueda hacer, es que, de nuevo, necesita una base de datos, como hace el OPF que si parchea específicamente muchos. Y eso, nenes, es MUCHO CURRO.

Hombre, yo hablaba siempre desde el punto de vista del programador. Simplemente con seguir unas mínimas precauciones ya estaría todo bien.

Por ejemplo, a tenor de lo que comentas de que la RAM esté en slots diferentes para los 32k superiores e inferiores, recordarás la solución que te propuse para la rutina que coloca la página 2 del cartucho. Es algo muy sencillo, sólo consume 6 bytes extra y funciona bastante bien.

Ramones, no estoy de acuerdo contigo con que hacer un cargador superinteligente sea MUCHO CURRO, porque yo diría que es sencillamente ¡Imposible!, y es que no es viable computacionalmente analizar y parchear una ROM en el 100% de los casos con el 100% de efectividad, y para los casos en que se pueda hacer, los recursos propios de un MSX se quedan más que cortos.

Pensad, que ni siquiera es nada trivial, ni siempre resoluble, hacer un algoritmo que dado un programa distinga sin dudas que es datos y que es código, cómo para ponerse además a parchear cada caso particular para cada uno de las posibles soluciones en canto a la distribución de la memoria... Como mucho, se podría hacer una ROM 'loader friendly', estableciendo unas reglas o rutinas estandarizadas para la búsqueda y selección de slots, o que metamos marcas en el código para que el loader sepa qué hacer...

Pero como dice SapphiRe, sería mucho más sencillo tener cuidado a la hora de programar la ROM, o incluso seguiría siendo más sencllo preparar dos versiones del mismo juego, una pensada para ROM y otra para RAM que dejar la responsabilidad en un cargardor.

Saludos

Es que, sencillamente, el problema de saber qué hace un programa sin ejecutarlo no es computable.

Estamos parcialmente de acuerdo. Analizarlo en tiempo real, es decir, hacer un
programa genérico es imposible. Pero como imposible no hay nada, ya daba la
solución para que sea "posible". :D


A veces lo más simple es lo más efectivo. :) Os liais mucho a veces cuando la
solución está delante de nuestros morros. ;)

La solución que proponía, y que *ya es funcional en el OPF (cargador de Roms en
la MegaFlashRom de Pazos), que YA es funcional en el openMSX, y que será
funcional en un cargador de RAM es tan sencillo como tener una BASE DE DATOS. :D
Algo tan sencillo como leer, por ejemplo los 256 primeros bytes del programa a
cargar, hacer un CRC sencillito (lo tengo hecho) y averiguar si es un juego
"parcheable". Una vez que tienes el juego que es APLICAS el parche
correspondiente al cargarlo. Y eso implica MUCHO CURRO. Y a eso me refería. Que
primero has de saber por qué falla, luego saber arreglarlo (desensambla y
parchea cuando no vas a tener los fuentes), aplicar el cambio y cargar. Y esto
lo multiplicas por cada juego que quieras.

Ya te digo, el propio openMSX lo hace para detectar el mapper de la Rom que
cargas. Lo cual es lo mejor porque es 100% seguro, y no como los programas que
intentan "detectar" el mapper (cómodo para el usuario) que pueden fallar.


Esto no se le puede obligar a nadie. Si alguien hace un juego y el formato es en
ROM, normativa del concurso, ha de pensar que funciona así. Los "dulces" se
pueden hacer... como comenta Fernando, algunos problemas se solucionan de una
manera sencillísima con un mínimo código extra. Otros problemas pueden ocasionar
al programador/es/a/as un quebradero de cabeza y complicar su programa con
extras que se salen de la base: el juego. :)

Aún así, y como esto va con cada persona, yo lo que he hecho en 8/16/32/48k
siempre ha funcionado en Ram, sencillamente para facilitar los testeos y no
tener que estar continuamente grabandolo en una flash.

En fin, que si alguien se anima a hacer un cargador en Ram de juegos de 8-48k
(como el ODO, ExecRom) y que analice los juegos parcheándolos bien, pues que lo
hagan que saldremos todos beneficiados. :) A mi no me mireis.

Yo había entendido lo del 'superinteligente' como un loader tipo 'Juan Palomo, yo me lo guiso, yo me lo como'... Con el método de la chuleta de parches claro que es posible, porque así el cargador sabe lo que hay que hacer y como, incluso, puede aplicar distintas soluciones ante el mismo juego dependiendo de la configuración de la memoria del equipo.


Claro, detectar el mapeador desde un emulador a veces es imposible, ya que esta información no está el archivo .ROM, y un MSX hardware no tiene que 'saber' nada del mapeador, simplemente funcione porque cuando va a buscar un byte el mapeador le da lo que necesita. Pero bueno, hacer un cargador con estas opciones de base de datos y parcheo a partir de uno que ya exista tiene curro, pero tampoco es algo inabordable, y al fin y al cabo se hace una vez para todo los juegos, lo que sí que tiene curro es el proceso manual de parchear cada juego nuevo.



Estamos de acuerdo, no se puede obligar a nadie a hacerlo, como si a alguien le da por mandar una ROM hecha exprofesa para no funcionar en RAM con todas las técnicas que estamos comentando por aquí. Los jueces deberían de ignorarlo siempre que funcione desde ROM en cualquier máquina.


Aquí quería de llegar yo, aunque no se pueda obligar a nadie a hacer una ROM que funcione en RAM, creo que si desde el principio del desarrollo se tiene cuidado, sale prácticamente sólo. Porque, quitando las reglas de la DEV, también es una pena que alguien le dedique montones de horas a un desarrollo, y luego por un problema con los loaders menos gente juegue con él, cuando hubiera supuesto sólo un par de horas más de trabajo, o incluso ninguna si se plantea bien desde el principio.

Saludos

En efecto, a eso iba. Y teniendo la chuleta, para el usuario es igual de sencillo. No tiene que especificar nada de nada, pues al leer la Rom el programa sabe cual es y actúa en consecuencia. De hecho esto es lo que hace la propia Konami para detectar si hay un cartucho en otro slot cuando quieren activar cheats, extras, etc... o el propio Game Master.


Está a medias, pero no completa. Leyendo unos 16k o cosa así, normalmente se puede averiguar el tipo de mapper. Pero no siempre. Y si el mapper es "rarito", tipo R-Type, ya ni de bollo.


Claro que no es inabordable. Pero lleva HORAS y HORAS de chequeos. Y por ejemplo, preparar que todos los juegos del Dev FUNCIONEN con esas utilidades cuando van a salir, ya necesita de que el autor del programa los tenga antes. Y sobre todo sería hasta interesante ayuda por parte de los participantes/programadores.






Exacto! Y aquí es donde yo he ido siempre... ¿cómo comprueban los jueces que funcionan en un MSX? Es complejo, ya digo, porque tienes que tener un buen equipo. Pero me parece una excelente idea que si por un casual un programa no es 100% compatible y tiene problemas, se le pueda aplicar algún punto negativo. Y así premiar a quien hace las cosas como tocan.



Es que, y este es otro problema, me parece que hay demasiada gente que solo juega en emulador. Que realmente ponen 5 minutos el programa, lo ven y lo dejan. Otro de los problemas potenciales del soft gratuito.

Volviendo al tema del hilo... Estuve jugando un rato a La Corona Encantada. No me lo acabé, pero llegué a las 15 gemas o así. Jugando en un Turbo R, tras meterlo en el Megaflash, creo que encontré un "problemilla". Hay algunos tiles que se corrompen con el tiempo. Las monedas, por ejemplo.

Aparte de eso, debo decir que me parece entretenido el juego.

Es raro que se le corrompa en el turbo R algo a 60hz, pues ... ah vale... nada, es que el Turbo R mete esperas en el VDP, pero solo cuando está en R800 (creome recordar). Así que el problema es que a 60hz se corrompe algo. Pues tendrías que mirarlo Jon, puesto que si en un MSX2 o superior se corrompe algo a 60hz, en un MSX1 a 60hz será la risa. (no, no lo he podido probar).

También puede ser todo el mismo tema de la pila del que hablamos ya, y puede que te estés machacando tus variables y cosas. Míratelo.

Lo voy a chequear, tal vez sea el tema de la pila, que ya tengo corregido. Dudo que haya problemas con las transferencias por frame, ya que son muy pequeñas (y uso la BIOS para transferir), así que en principio ahí no debería haber ningún problema.

No, no creo que tenga que ver con las transferencias. El problema era que, tras jugar un rato, el tile inferior derecho de la moneda se corrompía, y se quedaba corrupto.

Si hablamos de "tras jugar un rato", suena más bien a problema de corrupción debido a la pila... Aunque tampoco tiene mucho sentido. ¿O sí?

Este mismo problema lo tenía el Malaika. Cuando jugabas y te pasabas la primera fase se corrompía todo. Y si, era por la pila pues estaba metida en la zona de variables del juego. Y eso no veas que risas puede provocar... desde que no funcione nada, a que se descomprima mal, etc, etc...

En fin, poneros "las pilas". Si quereis claro, que parece que os obligue y solo lo comento para que las versiones funcionen y sobre todo si hay intención de sacarlas en cartucho.

Además, le comenté en privado el tema a Jon para evitar que se malinterpretase como una "puya" y sonrojarle en público. Aunque no es la intención ni mucho menos y si se explica para un juego más gente puede ver la información y aplicarlo en sus programas.

Pero bueno, que ya no molesto más. :)

En cualquier caso, Armando, también yo he optado por la senda del dolor que seguís en Kralizec. De ahora en adelante, todas las producciones en las que me encargue de la programación serán compatibles con 8 KB de RAM. De hecho, ya tengo un juego casi listo para ser publicado y que cumple con esto. Y otro más, del que tú viste una versión alfa hace muuucho tiempo, también. Reciclar RAM te obliga a usar mucho ingenio, pero en general da lugar a una programación más eficaz.

A ver si os pasais 'la corona encantada' con este joystick.

http://www.youtube.com/watch?v=8JORtc2gAsY (http://www.youtube.com/watch?v=8JORtc2gAsY)

;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

Pues no me imagino una partida a dobles con el Track and Field y este joystick  :P

En la prueba de halterofilia puede ser criminal. XD