Karoshi MSX Community
05 de Julio de 2021, 09:41:09 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: 1 2 3 [4] 5 6 ... 19
  Imprimir  
Autor Tema: MultiROM de Pazos  (Leído 115033 veces)
0 Usuarios y 2 Visitantes están viendo este tema.
MsxKun
Karoshi Forum's Guru
*******
Mensajes: 1554


Kimochi-ii


WWW Email
« Respuesta #45 : 28 de Noviembre de 2006, 03:13:38 pm »

Ya podéis llevar dinerín a la RU, que igual os encontráis Karoshi-cartuchos con su cajita, manuales, etiquetas, etc... cough, cough... ¿quién ha dicho esoooooo? Wink.

Sóputos... el año que viene me oireis....  scrms:)
En línea

--

Cindy Lauper She Bops!
burguera
Visitante
« Respuesta #46 : 28 de Noviembre de 2006, 04:29:42 pm »

Con el de Pazos ya veré si hay segunda tirada para los que no vamos a la RU.
¿Y los de Karoshi? ¿Pensáis dar oportunidad a los que no vayamos a la RU?
En línea
SapphiRe
Visitante
« Respuesta #47 : 28 de Noviembre de 2006, 06:18:02 pm »

Volvemos a la polémica de ASM vs. C... Roll Eyes en fin Roll Eyes

En un ordenador con tan pocos recursos (comparado con los actuales) como es el MSX, yo estoy a favor del uso exclusivo del ensamblador. Tal y como dice el viejo archivero, tienes un control mucho más fino de la máquina y si al final vas a embeber ASM en C pues es algo más complicado de seguir el código.

Mis listados en ensamblador están hipercomentados (un comentario por línea) y ahora trabajo mucho con "punteros" que se calculan en tiempo de compilación (por ejemplo ld a,[PLAYER1+SCROLLTABLE], si alguien está interesado en echarle un vistacillo Grin por encima Grin al código del QBIQS que hable conmigo en la RU) para una mayor claridad en el código. No digo que con C no se trabaje bien, pero yo no me quedo contento sin saber cómo se las apaña el compilador de C para producir ASM, ya que estoy seguro de que en multitud de ocasiones va a estar metiendo código espúreo que se puede evitar programando directamente en ensamblador.

Y aquí quiero poner un ejemplo. Me gustaría que alguien compilase un simple CASE con tres o cuatro comparaciones del valor de una posición de memoria con una serie consecutiva de números y nos pusiera el resultado aquí. Quiero decir algo como:

Código:
switch (valor posicion 6000)
{
case 0:jp 5000
case 1:jp 5003
case 2:call 4000
default:ret
}

¿Cómo lo traduce C? Me gustaría verlo, ya que en ASM yo lo haría así:

Código:
ld a,[6000]
or a
jp z,5000
dec a
jp z,5003
dec a
call z,4000
ret

Y apuesto a que un compilador automático no puede llegar a ese nivel... ojalá me equivoque.

Con respecto a si pruebo los programas en un MSX real: sí, pero cuando están en una fase ya avanzada del desarrollo. Los pruebo en un MSX1 y en un Turbo-R y pido a la gente que los intente probar en otros modelos para ver qué tal funcionan.

Saludos
--
Sph.
En línea
SapphiRe
Visitante
« Respuesta #48 : 28 de Noviembre de 2006, 07:11:35 pm »

¡Ea! Para aliviar la presión de la eterna lucha entre lenguajes, aquí os va una cosilla que acaban de pasarme:

Empty your memory,


with a free()...


like a pointer!



If you cast a pointer to an integer,


it becomes the integer,


if you cast a pointer to a struct,


it becomes the struct...



The pointer can crash...,


and can Overflow...



Be a pointer my friend...
En línea
Dioniso
Visitante
« Respuesta #49 : 28 de Noviembre de 2006, 09:06:22 pm »

Todas? Smiley ¿He dicho yo eso? Solo digo que son probadas pocas.

Claro, sólo has dicho que las probemos todas a ver qué pasa ...  Smiley

Citar
Viendo los resultados del Dev del año pasado y como se quitaban y daban puntos, me sorprende actualmetne mucho que juegos como ... ¿era tuyo? bajasen puntos por hacer escrituras "feas" en el PSG, y no se bajasen puntos por usar directamente los puertos del VDP, como es el caso de The Cure y UU.

Lo del chaval aquél fue un poco una pasada. El Magical Stones hace escritura directa a los puertos. Tan sólo al principio utilizo la BIOS. Pero leer teclado, enviar datos a VRAM, leer de VRAM, etc ... es algo que quiero controlar al milímetro, que nada se me escape. Hice pruebas varias en emulador. Una vez que funcionaba pasé al turbo-grande y aquello no iba de ninguna forma (aquello me tocó los puertos de los h**v*s directamente). Cuando funcionó saqué el MSX1 y la unidad externa ... los t-states de pausa no eran suficiente ... En fin, una odisea. Pero la versión 16k va en cualquier MSX, con escrituras directas a puertos, y las escrituras "feas" al PSG (bueno, ya no). Supongo que por eso no me dió ni un 5 por mi juego  Angry

Una vez quemé un Philips 8235, con ampliación de Padial de 1 mega y un cartucho coreano con 500 (este número puede ser una exageración andaluza y no corresponder con la realidad)  juegos de konami por querer copiar el cartucho, en caliente ... Pero NUNCA me ha pasado NADA por escribir 00 en los dos bits más altos de aquel registro hoy maldito  Grin Penguin Race, T-Virus, Gniffel y Magical Stones (éste último ya no  Wink ) escriben de esa manera ... ilegal? así es que cuidadín. Alguien ha escuchado algo, a alguien le ha pasado algo alguna vez?
En línea
jjfranco
Visitante
« Respuesta #50 : 28 de Noviembre de 2006, 09:23:42 pm »

Pues yo estoy de acuerdo con JJLopez en una cosa, no solo de cartuchos vive el hombre.

¿ por que no hacer juegos en disco, aunque haya que utilizar un MSX2 ?
En línea
nerlaska
Karoshi Excellent Member
******
Mensajes: 1102


Programador


WWW Email
« Respuesta #51 : 29 de Noviembre de 2006, 08:45:01 am »

Por poder .. se podría .. pero leches .. el encanto del megarom es la bomba .. además el año que viene .. va la primera producción MSX2+SCC+512 de una larga lista por parte de Nerlaska y eso en disquetes como que no. Yo apuesto por el cartucho!!!
Y sobre el C y el ASM .. en fin .. que cada uno haga lo que le salga de los EGGS!!! jejejeje .. al final programar es programar en lo que más a uno le guste y ya está.
Por cierto .. el compilador de C .. al menos el SDCC .. por un swith te crea una tabla de saltos o no .. según tu se lo indiques.
Sobre lo de que genera sobras .. no te lo voy a negar que en muchas ocasiones las genera .. pero donde las genera y el profiler me dice .. YEP!! .. voy yo y le meto ASM .. al final són solo funciones donde tienes ASM inline .. la estructura y cuerpo del programa esta toda en C que sin duda es mucho más visual y atractiva (por miles de comentarios que pongas en ASM)
Pero ya no voy a decir nada más! jeejejejejej .. y ahora .. a ver si termino el MSXScript para dar opción a los usuarios MSX-BASIC de aumentar sus posibilidades. Si es necesario y así me lo dicen . .estoy hasta por cambiar la gramática y hacerla lo más parecida al MSXBasic.
En línea

MSX4EVER2GETHER
www.nerlaska.com
JLLopez
Visitante
« Respuesta #52 : 29 de Noviembre de 2006, 09:12:13 am »


Te lo juro, tengo MSX1, MSX2, MSX2+ y TR y todas mis ROMs fueron probadas en todos y cada uno de ellos. Es más, es uno de los requisitos del certamen, si en algún momento se ha levantado algo la mano, bueno, ese es otro problema.

Hombre, digo yo que exigir la compatibilidad en la familia MSX, no se debería ni mencionar ... lo tendríamos que tener asumido .... Smiley Supongo que los pobres que tenían un MSX2 y probaban los juegos de cinta creados en este país recuerdan perfectamente lo que significa programar mal y sin tener en cuenta la compatibilidad. (Aunque estoy 100% seguro que a esta gente le pagagan 4 pesetas por conversion y no tendrían NINGUNA documentación técnica). Hoy en día creo que tenemos mucha más ventajas en este aspecto.


El que no sea compatible con alguna de las familias desde mi punto de vista es un fallo grave, menos grave; pero seguro que más frecuente es el problema de las frecuencias, ajustar el juego perfectamente para que funcione igual a 50Hz ó 60Hz no es moco de pavo (yo mismo metí la pata con el tema Angry)

Para que funcione exactamente igual, si, es difícil. Mucho. Un detallazo si alguien se trabaja que el juego funcione igual a nivel de "todo" en 50hz y en 60hz. La música es más o menos arreglable, pero lo que es la velocidad del juego ya es más peliagudo. Aunque bueno, lo suyo es hacer todo a 50hz y saltarte 1 frame de cada 6 en 60hz. Es una chapuza pero dará el pego. Al revés ya es más peliagudo.


Citar
Venga, que nos lo digan. Smiley En mi MSX1 Universe Unknown no funciona correctamente cuando se ve la intro y despues vas al juego. Tiene un momento de fallo que no se da en emuladores ni en MSX2.

Es que los chicos de Infinity corrieron la última semana como alma que lleva el diablo, sólo de pensarlo se me ponen los pelos como escarpias Cheesy

Y ... ¿qué tiene que ver correr con hacerlo mal? Es decir, está claro que las prisas son malas, pero no es culpa de nadie. Si está mal, esta mal, no hay excusas, digo yo.


Es una cuestión de proporciónes y magnitudes, es decir, el 99,99% de los equipos de la norma tienen como puertos del VDP el $98 y el $99 (que yo sepa sólo ciertos equipos brasileños que incorporaban no se que ampliación veían modificados estos puertos), por esa razón se asume como bueno el uso de esos valores.

Asumir ... no me gusta esa palabra. Esta claro que asumimos muchas cosas, muchas direcciones de puertos, pero lo del VDP es algo mas complejo. Si como tu bien dices hay equipos que no usan esos, es que hay que trabajarse que no se escriba directamente en los puertos. No creo que sea tan complejo. Por ahí deje yo la rutina de descompresion del bitbuster con 1 byte de ram y no usa los puertos directamente, y chicos ... tampoco es tan grande la diferencia de velocidad.

Y repito: ¿Me puedes dar documentacion OFICIAL de MSX1 donde diga que puedo usar esos valores? Tu explicación está bien, pero no es oficial. Tongue

Es que en el TH del MSX2 lo veo claro, lo pone, pues así es. En MSX1 no.

Por supuesto en el peor de los casos el software no funcionará en esos equipos.

No, no funcionará. Si usan otros puertos, adios, no te va. Y para mi es un caso MUY grave, más que se pueda romper algo que no se rompe con lo del PSG. Y es que lo gracioso es que la mayoria de ROMs comerciales de la época seguro que si van en donde fallan esos juegos. Hete aquí la diferencia entre hacer las cosas mal, y hacer las cosas bien.

Como norma general, usar directamente los puertos $98 y $99 (si se tienen remordimientos de conciencia se pueder hacer una rutinilla que lo compruebe al principio y que avise en caso de incompatibilidad). En el caso del PSG el arreglo es muy barato, es mejor vigilar que se escribe en el PSG#7 y quitarse de problemas.


Repito: Agradezco tu mensaje, de verdad, pero creo que no voy a hacerle caso. Smiley No estoy nada de acuerdo con usar directamente los puertos del VDP en MSX1. Y es grave, muy grave.

En línea
JLLopez
Visitante
« Respuesta #53 : 29 de Noviembre de 2006, 09:35:44 am »

Claro, sólo has dicho que las probemos todas a ver qué pasa ...  Smiley

Más que otra cosa, lo digo para que no pase más. Si ha pasado, pasado está. Pero que no pase más en juegos nuevos. Cheesy



Lo del chaval aquél fue un poco una pasada. El Magical Stones hace escritura directa a los puertos. Tan sólo al principio utilizo la BIOS. Pero leer teclado, enviar datos a VRAM, leer de VRAM, etc ... es algo que quiero controlar al milímetro, que nada se me escape. Hice pruebas varias en emulador. Una vez que funcionaba pasé al turbo-grande y aquello no iba de ninguna forma (aquello me tocó los puertos de los h**v*s directamente). Cuando funcionó saqué el MSX1 y la unidad externa ... los t-states de pausa no eran suficiente ... En fin, una odisea. Pero la versión 16k va en cualquier MSX, con escrituras directas a puertos, y las escrituras "feas" al PSG (bueno, ya no). Supongo que por eso no me dió ni un 5 por mi juego  Angry

Bueno. La puntuación de un juego siempre es algo complejo, y es muy difícil hacer de jurado. Ese mérito no se le puede quitar. Lo único que veo mal es que no se puede ser más papista que el papa con una cosa y dejar de pasar otra. Si no se dice nada de lo del PSG, pues no pasa nada, pero si se dice habría que ser igual de quisquilloso con todos los programas.

En línea
JLLopez
Visitante
« Respuesta #54 : 29 de Noviembre de 2006, 09:41:50 am »

Pues yo estoy de acuerdo con JJLopez en una cosa, no solo de cartuchos vive el hombre.

¿ por que no hacer juegos en disco, aunque haya que utilizar un MSX2 ?


Nadie te lo prohíbe. Cuanta más variedad se tenga, mejor para el usuario. Y juegos en disco se han seguido haciendo. Está claro que el cartucho tiene un lujo extra, eso no se puede negar. Pero el disco es más barato de producir. Todo tiene sus ventajas y desventajas. Wink
En línea
JLLopez
Visitante
« Respuesta #55 : 29 de Noviembre de 2006, 10:09:12 am »

Por poder .. se podría .. pero leches .. el encanto del megarom es la bomba .. además el año que viene .. va la primera producción MSX2+SCC+512 de una larga lista por parte de Nerlaska y eso en disquetes como que no. Yo apuesto por el cartucho!!!

Nene, nos estás poniendo los dientes largos con tanta producción futura. Smiley Y de momento solo tenemos un par de snaps que llevarnos a la cara. Mira que repito veces que no es bueno decir cosas que no se tienen, que luego es un agobio.... Tongue Mejor decirlas cuando se tienen.

Y sobre el C y el ASM .. en fin .. que cada uno haga lo que le salga de los EGGS!!! jejejeje .. al final programar es programar en lo que más a uno le guste y ya está.

Si, si está claro. Al final, todo es programar lo más agusto posible. Pero también al final se verá el resultado y si es mejor o peor programar en una cosa o en otra. Es lo de siempre, mientras todo es gratis, todo es agradecido.  Yo lo único que te quiero decir es que el Aleste2 no está en C, y dudo mucho que lo esté el Zanac.

Pero claro, luego existen juegos que no necesitan mucho, y se pueden hacer en cualquier lenguaje ... Todo depende del tipo de juego.

Por cierto .. el compilador de C .. al menos el SDCC .. por un swith te crea una tabla de saltos o no .. según tu se lo indiques.
Sobre lo de que genera sobras .. no te lo voy a negar que en muchas ocasiones las genera .. pero donde las genera y el profiler me dice .. YEP!! .. voy yo y le meto ASM .. al final són solo funciones donde tienes ASM inline .. la estructura y cuerpo del programa esta toda en C que sin duda es mucho más visual y atractiva (por miles de comentarios que pongas en ASM)

Ya, pero es que, de momento mi código es para mi y no tengo que ponerlo en un escaparate. Así que, si un código queda bonito y no queda efectivo, pues como comprenderás, no es ninguna ventaja. Tongue

Pero ya no voy a decir nada más! jeejejejejej .. y ahora .. a ver si termino el MSXScript para dar opción a los usuarios MSX-BASIC de aumentar sus posibilidades. Si es necesario y así me lo dicen . .estoy hasta por cambiar la gramática y hacerla lo más parecida al MSXBasic.

Hmmm... creo que lo que habría que hacer es intentar que no puedan programar en BASIC. Smiley Mira la diferencia abismal entre los juegos de Jon e Imanok en Basic y los últimos que han presentado (Infinity y TJ). Smiley

Ey! Por supuesto, que nadie se ofenda con todo esto, por favor. Tongue


En línea
jltursan
Karoshi Forum's Guru
*******
Mensajes: 1516


¿Que es lo que has aprendido hoy?


WWW Email
« Respuesta #56 : 29 de Noviembre de 2006, 10:29:44 am »

Citar
¿Me puedes dar documentacion OFICIAL de MSX1 donde diga que puedo usar esos valores? Tu explicación está bien, pero no es oficial. Tongue

Es que en el TH del MSX2 lo veo claro, lo pone, pues así es. En MSX1 no.

Por supuesto, "The MSX Red Book", Cap.2 VIDEO DISPLAY PROCESSOR, apartados "Data Port" y "Command Port". Y si me apuras basta con que mires la BIOS de (casi Roll Eyes) cualquier MSX1, verás como se accede directamente a esos puertos. Esto último no es muy relevante ya que las BIOS están para eso, enmascarar el hardware; pero por lo menos ilustra el problema, la solución que resultó más práctica es tener versiones de la misma ya que una única BIOS que se adaptara a esos cambios (los puertos del VDP) habría resultado económica, sólo una BIOS para todos los modelos; pero habría resultado lenta.
En un juego sucede igual, puedes optar por parchear dinámicamente todas las operaciones sobre el VDP (si no es una ROM) o tener rutinas que eviten el acceso directo y utilicen sólo el indirecto via C. Si la velocidad es una necesidad; ¡pues tenemos un problema! Smiley

Citar
No estoy nada de acuerdo con usar directamente los puertos del VDP en MSX1. Y es grave, muy grave

Totalmente de acuerdo; pero hay que reconocer que las soluciones son, en este caso, lentas y engorrosas Sad
En línea

Doom dee doom dee doom
JLLopez
Visitante
« Respuesta #57 : 29 de Noviembre de 2006, 10:54:31 am »


Por supuesto, "The MSX Red Book", Cap.2 VIDEO DISPLAY PROCESSOR, apartados "Data Port" y "Command Port". Y si me apuras basta con que mires la BIOS de (casi Roll Eyes) cualquier MSX1, verás como se accede directamente a esos puertos.

Exacto, pero tal como comentas es lógico. Si tu haces una BIOS y sabes que tu máquina funciona así no es necesario que tu mismo te leas a ti mismo. Además ya ponen los puertos que son en la BIOS para que sepas como ha de funcionar.

Totalmente de acuerdo; pero hay que reconocer que las soluciones son, en este caso, lentas y engorrosas Sad

Sigo sin entender la lentitud. A ver, si tu coges los puertos y te los guardas en dos valores de Ram, ya lo tienes hecho. Es un "pelin" más lento que trabajar directamente, pero no tanto como para preferir hacerlo "mal".

A ver, ejemplo tonto teniendo los puertos en dos valores ram:

ld a,(vdp_reg98)
ld c,a
ld a,valor
out (c),a o outi, o lo que queramos.

Tan lento es?

Si es que además, luego el VDP del MSX1 se agobia qu eno veas, y hay que poner nops por todos los sitios para que no falle ... así que al final, si haciendolo así, puedes quitar un nop de "agobio" el resultado final es exactamente el mismo, no crees? Wink












En línea
nerlaska
Karoshi Excellent Member
******
Mensajes: 1102


Programador


WWW Email
« Respuesta #58 : 29 de Noviembre de 2006, 11:19:10 am »

Bueno JJLopez .. tienes razón (no en todo claro Smiley) pero si en cuanto a que hablo mucho y he enseñado poco. También es verdad que no enseño más porque no me da la gana. Aún así para la RU pienso llevar una demo del Monster Hunter en cartucho para que la gente lo vea, lo mire, lo juegue y me ponga a parir, claro Smiley
Por cierto .. ahí ya podrás ver lo que se puede hacer en C, ah! .. y es perfectamente posible hacer un Zanac y un Aleste y sino esperate al año que viene .. yo cuando digo las cosas las hago. No hablo por hablar.

Sobre lo de la BIOS .. hombre .. yo empece montando todo el motor gráfico con acceso directo a VDP .. iba como una bala! .. se me ocurrió dar a probrar la ROM en MSX1, 2, 2+ y TR .. y en cada uno de ellos pasaba una cosa distinta jejejejej Cheesy
Así que dije .. me cago en la puñeta! .. pues ala BIOS .. y hombre .. ha sido pasar a BIOS y todo rular fino aunque no tan rápido (yo calculo casi la mitad de rápido)
Ahora si puedo decir que lo que veo en el emulador es lo que veo en mi MSX1, sin sorpresas.

Creo que TODOS deberiamos normalizarnos y usar BIOS .. es la única forma REAL de asegurarse no tener ningún problema en ningún MSX. Tengo que decir que se puede hacer DE TODO usando BIOS .. y eso que yo programo en C que según muchos es muy lento y bla bla bla.

En línea

MSX4EVER2GETHER
www.nerlaska.com
jjfranco
Visitante
« Respuesta #59 : 29 de Noviembre de 2006, 11:43:16 am »

Por poder .. se podría .. pero leches .. el encanto del megarom es la bomba .. además el año que viene .. va la primera producción MSX2+SCC+512 de una larga lista por parte de Nerlaska y eso en disquetes como que no. Yo apuesto por el cartucho!!!

Buen argumento para no utilizar un sistema de almacenamiento que ha durado mas que el propio MSX

Pues yo estoy de acuerdo con JJLopez en una cosa, no solo de cartuchos vive el hombre.

¿ por que no hacer juegos en disco, aunque haya que utilizar un MSX2 ?


Nadie te lo prohíbe. Cuanta más variedad se tenga, mejor para el usuario. Y juegos en disco se han seguido haciendo. Está claro que el cartucho tiene un lujo extra, eso no se puede negar. Pero el disco es más barato de producir. Todo tiene sus ventajas y desventajas. Wink

Hombre prohibir, prohibir, pues no.

Pero yo, que no he tenido experiencia con el ensamblador del Z80 hasta hace apenas un año, y que la motivacion para apender ha sido la edición de la Dev de este año, me he visto obligado a presentar mi primer programa en ROM para la MSXdev (por supuesto son las reglas del concurso y me podia haber estado quietecito sin hacer nada).

Sin embargo se podría haber ampliado la presentacion de juegos en cualquier formato(disco o rom), incluso en cualquier lenguaje(incluido el Basic, o combinacion Basic-Ensamblador) y sin limitaciones, valorandose solo el producto final  con lo que ganariamos con seguridad toda la comunidad.
En línea
Páginas: 1 2 3 [4] 5 6 ... 19
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!