Karoshi MSX Community

Hola a todos.

Bien, hace unos días, tanto Manuel Pazos, como Edu Robsy como un servidor, empezamos a discutir de la validez o no validez del conocido por estos foros como "modo mixto".

En resumidas cuentas, usar un solo set de patrones y colores para las 3 zonas de patrones/colores de Screen 2. Se ha hablado mucho, y se llegó a la conclusión por lo leido que era incompatible.

Edu me comentaba que su "Picture Puzzle" usaba ese modo y daba problemas en casi todos los Sony, probado por ellos mismo en el Sony de Jon. Bien, cual sería mi sorpresa al ver que ni en mi HB20P ni en un HB75P de Manuel Pazos da ningún problema. Todo funciona a la perfección. E idéntico resultado con todos los juegos de la Dev de todos los años, si es que alguno más ha usado este modo.

Este modo, es totalmente compatible en la familia de VDPs de MSX2 y superior. Yo mismo lo he usado en Dahku (Screen 4) sin conocer ninguna incompatibilidad, y creome que los juegos de Matra hacen uso del mismo, y tampoco se conoce ninguna incompatibilidad.

De modo, que la mejor manera de saber si es realmente compatible en MSX1, es decir en el TMS o derivados es hacer pruebas. Y para hacer pruebas, pues necesitamos la colaboración de todo aquel que puerda perder un momento en ejecutar esa Rom que aquí os adjuntaré.

Si fuese compatible seria un gran avance para los desarrolladores, puesto que el tener que actualizar un solo set libera a la cpu muchísimo para crear según que efectos ... hablamos de scrolles y cosas parecidas.

Una advertencia. Por lo que hemos podido deducir, el problema del Picture y puede que de otros juegos no fuese el modo mixto en si. Si no mandar los valores para cambiar de modo directamente al VDP y tocar sin querer el bit que activa el modo de 4k de VRAM.

Así pues, pido en nombre de todos vuestra colaboración para testear en todos los MSX1 posibles. MSX2 no nos vale, sabemos que funciona correctamente. :) Y ya sabeis es por el bien de futuros desarrollos... :P


Lo que adjunto en un ZIP que contiene la ROM de 8k y el código que la genera para que todo el mundo vea como se posiciona el modo mixto (no tiene ningún misterio).

Si al ejecutar la ROM veis 3 patrones blancos en pantalla, la cosa va bien. Si solo veis el superior, es que ese modelo no es compatible, ok?

En fin, lo dicho, que gracias de antemano por vuestra ayuda!









 

Pues lo bajo y lo probare :) Tengo 4 MSX1 y 2 de ellos son Sony, el 20P y el 75P, asi que seran buenos conejillos de indias (y en este caso sin diñar). Se que en uno de los efectivamente a mi me fallaba el modo mixto ese.
A ver si funciona, seria muy util :) Ya informare!

¡Lo mismo digo!, buena iniciativa. Yo lo trataré de probar en mi Sony HB75P (a ver si hay diferencias entre idénticos modelos) y en el Sakhr AX-170

Gracias a ambos.

Aunque el problema parecía más extendido en los Sony, agradezco que lo probeis también en otros MSX1.

Toda prueba será buena. :)

No tengo mi batería de MSX1 por aquí, pero haré las pruebas en el mini-set que tengo montado en Barcelona (SANYO MPC-100 y PHILIPS VG-8020).

Primera prueba:

- Rom del Picture Puzzle en el 75P, se ve perfecta
- Rom mixto en el 75P, se ve perfecta
- Rom del Picture Puzzle en el 20P, solo se ve el primer tercio :(
- Rom mixto en el 20P, tambien se ve solo el primer tercio :(

Primera conclusion:

El HB20P fue mi primer MSX y mi primer ordenador, y merece un VDP en condiciones!  >:( Le puedo transplantar el del 75P? :P Cagontó.. ya podria ser al reves... :S

El finde con mas tiempo, probare en los otros dos MSX1, el Philips 8020 y el Panasonic, que no los tengo tan a mano...

Saludos!

Ramones, mis pruebas coinciden lamentablemente con las del Kun...

HB10P.- Solo el primer tercio, tanto la prueba como el Picture Puzzle  :'(

Sólo he ejecutado el test mixto.rom y en ambos equipos : el HB-75P y el AX-170 he visto los tres caracteres blancos que se supone que debo ver. He desmontado el Sony para tratar de ver el modelo de TMS; pero la verdad es que no es fácil, está completamente cubierto por otras placas. Probaré con el del AX-170...

Muy curioso el tema de que en algunos HB-20P sí funcione y en otros no. Tenemos aquí dos caminos:

(a) Verificar que el chip gráfico sea distinto en unos y otros (quizás de distintas "hornadas")
(b) Buscar otro tipo de problemas: se han ejecutado las pruebas de modo distinto? Unos en RAM, otros en FlashRAM, etc. Esto no veo cómo pueda afectar a la compatibilidad de algo que tiene que ver con VDP.

Muy a mi pesar, parece que la opción (a) va tomando forma.  :'(

Eso supongo yo también, he tratado de ver que modelo incorpora el Sakhr (que en el fondo es un Sanyo MPC-200) y tampoco. Los chips estan debajo de la placa y tenía que montar un cisco. ¿Alguien puede abrir un HB-20P y tratar de ver algo?

Bueno, gracias a todos por las pruebas.

Tiene cojones la cosa. :( Tengo DOS HB20P y me funciona correctamente en los dos. :/ Hace poco adquirí otro HB20P pues el mio (mi primer ordenador y MSX) tenía el teclado destrozado por un ... accidente, y quería tener uno intacto pues le tengo cariño.

Pues tiene puñetas que en ambos funcione y en el de Kun falle.


Creo que la opción a) de Edu va a ser la definitiva. Tienen que llevar OTRO chip gráfico que no es el TMS original. Estoy totalmente seguro que en un TMS normal funciona, como hemos podido ver.

¿Alguno de los dos (Kun o Jon) se atreve a abrir el ordenador para ver que chip lleva?

Kun, si un día quieres podría quedar contigo para ver ese HB20P y hacer más pruebas. De esa manera igual encontrábamos la forma de hacerlo funcionar ... o no. Pero me gustaría hacer algunas pruebas más (aunque ahora mismo no se me ocurren cuales).

En fin, que mil gracias a todos... y nuestro gozo en un pozo si esto se confirma. :(

mañana lo probare con mi sony hb-55p, a ver qué ocurre, además, tengo suerte que está medio abierto (estoy intentando arreglar el teclado)

Saludos

Eso es lo mismo que he pensado yo y que lo he dicho más de una vez: si un programa va en el 9X % de los MSX y falla en unos pocos, el fallo no es del programa, sino de los MSX en cuestión, sobre todo en este caso (no me refiero a las conversiones mal hechas de Spectrum que fallaban en segun que MSX ;D)

No Salva, por desgracia esto no es así. :( Este modo mixto no es algo legal. No está en las normas del MSX, por lo que si en esos ordenadores donde falla, van todos los programas que no se salten la norma, esos MSX están bien.

Edu abrió un hilo llamado "Legalidad Vigente" o algo así, donde explicaba un montón de cosas que los programadores nos saltamos a veces a la torera. El problema es que hoy en día se hace todo en ensambladores cruzados (usando windows, linux, macos), se prueba en emuladores y luego cuando se prueba en la máquina real normalmente es un MSX2 y superior, con lo que muuuchas cosas funcionan, pero no tienen porque funcionar en MSX1. 

Y si el programa lleva el sello de compatible MSX1, debe de preocuparse de que esto sea así. 

Pues nada, que nos tendremos que ir olvidando del mixmode este ... a no ser que se nos ocurra como hacerlo funcionar en todos los vdp, sean originales o sudedáneos ...   :'(

El mio lo he abierto 100 veces. Pero es que es tontería pues en los dos mios funciona correctamente. Y si que lleva el chip original. Sería interesante ver que chips llevan los Sonys de Kun y Jon.

A la noche pillaré el destornillador (vodka con naranja, mmmm....) y veremos que se esconde en el interior de la bestia nnchks:)

Muy bien Jon! Con 2!

Lo del modo mixto será una discusión eterna. Estaría bien ver que algunos modelos tienen un chip de video diferente pero eso sólo serviría para lanzar juegos con el modo mixto con la excusa de que esos modelos "no son MSX" ... Quizá, es una opinión: porque aunque descubriéramos que esos ordenadores son diferentes, no podríamos cambiarlo ... el modo mixto será incompatible, a no ser que se cambiase el chip de vídeo o lo que provoque esa "incompatibilidad".

Lo que Ramones intenta es experimentar en la máquina "rara" directamente ... desde aquí mis oraciones a San Nishi para que lo consigas. Eso nos evitaría muchos dolores de cabeza.  ;D


En el caso de que no se encuentre un método fiable:
Tengan o no tengan un chip de vídeo diferente, yo soy partidario de hacer juegos en modo mixto. Se perdería mucho si abandonáramos esta técnica. Se podría eludir perfectamente en la mayoría de los juegos, pero un proyecto tipo GnG o algún otro que requiera scroll píxel a píxel, por ejemplo (sé que van a aparecer varios en breve en modo SCREEN2 puro), se beneficiaría mucho del modo mixto. Algunos juegos serán imposibles sin el modo mixto.

Mi opinión es la siguiente: que cada uno haga lo que quiera, pero si alguien utiliza el modo mixto que avise ... y si pretende venderlo que saque una especie de demo/test antes de venderlo.

Mi pregunta es la siguiente ... alguien tiene tan sólo un MSX y que además ese MSX sea un MSX que no tolere el modo mixto?

COmo dice Dionisio .. sería interesante ver una estadística de la gente ..
Ver quien tiene MSX, MSX2, 2+ y TR.
A ver si va a resultar que TODOS tenemos un MSX2 o superior y estamos haciendo el canelo :-)

Bueno, esto para mi es indiferente. Pero es una opinión muy personal. Yo solo busco saber que puñetas pasa y si existe alguna solución para usar ese modo en TODOS LOS MSX1 DEL MUNDO y que funcione. Si no se consigue yo, como digo personalmente y por ideología propia, NO LO USARE.

Siempre he intentado respetar el sistema y no será ahora cuando me lo salte a la torera.  Y creo que todos deberíamos de hacer lo mismo, tener un poco de seriedad en ese sentido. Si queremos llegar a realizar programas como los profesionales del sector en su día, hemos de tener estas cosas claras.

Aunque claro, todo el mundo tiene derecho a hacer lo que quiera, claro está.

Y si no se pueden hacer scrolles gracias a eso, pues no se hacen. Tampoco son necesarios. Yo adoro los patronazos. :) Un juego es un juego y se ha de tratar como tal. Si tiene 100 scrolles y es aburrido, malo, mal diseñado e injugable, pues el scroll no ha valido para nada.

Es que un MSX es un MSX y lo que hay que hacer es juegos de MSX, no intentar hacer lo que no se puede. Hasta ahora se ha hecho así y no ha ido tan mal. ¿Alguien tiene queja de los Nemesis por los patronazos? ¿Y del Zanac? No pierden ni un ápice de jugabilidad por ello pues están diseñados específicamente así.

Fijaros en cualquier Nemesis (2,3, Salamander, Parodius). Cuenta el diseño. Nuestra nave nunca puede ponerse en el margen derecho (al tope) y así evitan que un movimiento de scroll te mate porque no has visto lo que viene. Es una manera muy simple de evitar problemas.

De todas formas, siempre hay soluciones. Creo que Exoide Z (Factor 5 o algo así) (puede que me confunda ahora lo reviso), lleva scroll cada dos pixels vertical, y lo consiguen sin saltarse ninguna norma. Claro, el aspecto gráfico es mermado. Y segun que Sapi me enseño una cosa en la Ru que tiene una pinta excelente y se realiza sin ningún tipo de modo mixto. Todo depende de como lo montes.

Asi que yo animo a todo el mundo a que intente respetar las normas. Animo, que no obligo. ;)

Hmmm ... de verdad, yo reconsideraría esto. Aunque claro, eres libre de hacer lo que quieras. :)

Si al final vas a usar un modo que solo va en MSX2 correctamente, pues para eso no uses SR2, usa SR4, ganas en sprites mejorados y tienes posibilidad de paleta y 64k de Vram mínimo.  ;)

No si .. a ver si me entiendes Ramones .. si estoy 100% contigo en cuanto a que para mi es más importante que sea 100% compatible MSX1 .. yo prefiero eso! precisamente por eso no me gusta el OCM (aunque es cojonudo que sea compatible MSX y hardware nuevo, bueno .. es otro tema)
Simplemente lo decía por curiosidad .. también de cara a desarrollar para MSX2 .. que esta un tanto olvidado.

Lo siento, no te había entendido. :)



Bueno. El tema es que si en OCM va todo lo desarrollado hasta ahora me parece perfecto. Pero si se desarrolla algo que solo va en OCM pues ya no me parece perfecto. Es idéntico al tema que estamos tratando. Así pues lo considero una buena máquina para experimentar con el VDHL para disfrutar de los programas de MSX, incluso para programar en ella, pero siempre que se siguan las normas y funcione en un MSX real.



Lo está, pero también lo estaba el desarrollo de MSX1 hace 4 años. Hay que buscar un equilibrio.

No estoy muy de acuerdo con la última afirmación. Hacer scroll pixel a pixel tratando con la tabla de patrones se me antoja una burrada de lento. Si ya descartamos trabajar con la tabla de patrones para ese tema ¿qué nos queda de ventaja? Pues tener ocupada una tercera parte de la VRAM que usamos en SC2 puro. Bien, pero esto tampoco es una cosa que los MSX1 puedan aprovechar, porque la tabla de patrones y la de color deben estar siempre en el mismo sitio (o intercambiadas), por lo que no podemos tener varios bancos de tiles en vram para intercambiarlos... ¿Qué ventaja sustancial nos da pues el modo mixto?

Creo que no es lo mismo mover "el mismo" bloque en los tres tercios que en uno sólo. Lo suyo sería ir sustituyendo tiles, no redefinirlos, pero si se tuvieran que redefinir algunos, puntualmente, sería mejor hacerlo una vez y no tres.

En el momento en el que se tengan que redefinir tiles la cosa va a ir más lenta... no se yo... Desde luego yo lo que hago es substituir tiles y visualmente no se nota nada. Si veo que tengo que usar más de 200 tiles en el scroll ya me las apañaré para conseguir un buen grafista que juguetee con los que quedan...

Pues actualización de un solo banco en lugar de 3 para patrones y 3 para colores cuando haces un scroll a pantalla completa. O un "cambio" a pantalla completa. Que no tiene que ser todo scrolles. Pueden ser mil efectos. No se, cambiar la tabla de colores para realizar una especie de efecto de paleta, o cosas así.

No es lo mismo mandar 4k a la Vram que mandar 12k. De forma que puedes hacer más cosas usando menos cpu, lo cual da como resultado que al final puedas hacer las cosas casi al frame.  :)

Ventajas tiene muchas. Y claro, como puedes elegir un montón de combinaciones (1 set, y que sea el 1,2,3, 1 set de patron y 3 de color, 2 de color y 2 de patron ....) puedes ingeniártelas para hacer cambios de set cambiando 2 valores en los registros de vdp ... ya ves con eso lo que se consigue, no gastar nada de cpu y tener un buen efecto.

Aunque el uso en MSX2, además de eso, lo use por otra cosa : El scroll vertical por hard, que es la única manera de poder hacerlo en SR4. Si usas los modos normales, no hay en la Vram para colocar los datos del "cuarto set" de colores y patrones. Entonces al scrollear por hard, se te muestra el contenido teórico de ese cuarto set (vamos lo que corresponderia de 192 a 255 en Y). Usando el modo de un solo set pues ya puedes hacerlo sin problemas.

Pero bueno. Que son ventajas para hacer cosas más espectaculares, que luego eso no quiere decir que el juego sea mejor. ;). Si no se puede no se puede y se busca la manera de hacer el juego para que funcione.

A veces es incluso más positivo el uso de SC2 puro. De hecho, en Malaika, usamos diferentes patrones para cada banco, así hay tiles que scrollean en una zona de la pantalla que comparten patrones con otros bancos (ejemplo, las tiles que son nubes en el cielo, corresponden con las que se utilizan para matorrales del suelo en otros bancos). De esta forma se enriquecen más los gráficos contando que tienes 768 tiles en total en lugar de 256, y encima evintando modificar patrones "on the fly". Por tanto, Malaika es carne de SC2 puro ;)

Además, la putada de tener que redefinir patrones para hacer scroll es que tienes un frame desacompasado... es decir, en 7 tienes que redefinir patrones, y en 1 tienes que redefinir y mover la tabla de nombres (porrón de bytes a VRAM). En el caso de tener todo bien predefinido en VRAM es que las transferencias son estables y nunca pasan de 768 en el peor de los casos... si encima recortas algo la zona de scroll (marcadores), incluso incluyendo la transferencia de sprites, sigue siendo MUY asumible.

De cualquier forma, esta discusión se me antoja muy positiva, en cuanto a que vamos comentando las vias posibles que cada uno estamos utilizando.

Lo del modo mixto yo creo que es más aprovechable para juegos de pantalla estable, en las que se pueden redefinir los patrones (llamas de antorchas, cintas mecánicas, fondos animados)... o incluso para hcer scrollers "multilayer" donde se puedan crear "tramas" con pocos caracteres para crear un fondo que scrolle a menos velocidad (efecto Vscreen): de este modo escrollearemos utilizando la tabla de nombres de dos en dos pixel, pero el scrollcito de fondo pixel a pixel puede basarse en redefinición...

I vote for mixed mode. And I have a new reason to use it (additional to those already posted).

The free VRAM you gain, can be used (and I use it) to store new sprite definitions.

This allows you to have nice and soft sprite animations.

With sprites 16*16, you can get up to 64*5 = 320 animation frames.

(The sole limit is that the animation frames change in a synchronized way for all the objects on the screen)

Bueno, y sin contar con la aplicación de ese modo mixto en demos, pantallas de inicio, etc...

Maravillas se me ocurren  ;)

A eso me refiero cuando digo que no es una ventaja. En un MSX1 con 16K de VRAM la tabla de patrones y la de color sólo pueden estar en dos sitios: 0 y 8192, una en cada lugar. El registro #4 del VDP sólo almacena los cuatro bits superiores de la dirección de inicio de la tabla de patrones (la cual es de 17 bits por el máximo de 128K de los MSX2). Si quedan 13 bits por debajo sin modificarse, eso significa que estas tablas sólo pueden colocarse en direcciones múltiplo de 2^13=8192. Por lo tanto 0 y 8192, porque la siguiente (16384) ya no es una dirección de VRAM válida para una máquina con sólo 16K de VRAM. Lo dicho para la tabla de nombres es válido para la tabla de colores pero referido a los registros #3 y #10 (consultar THB Capítulo 4a para más información).

¿O es que en el modo mixto las cosas cambian y puedes colocar la tabla de patrones en 0, 2048, 4096... etc? Si no es así, perdemos la ventaja de poder cambiar de set sólo cambiando los valores en los registros del vdp y esa es, a mi entender, la mayor ventaja de ese modo mixto.


Bueno, en MSX2 es otra cosa, ya que al parecer funciona correctamente en todos los modelos sin presentar ningún problema. Además, aquí ya tenemos un montón de VRAM para poder almacenar bancos de tiles para aburrirnos... 16 posiciones en total con 128K, casi na :D


Estoy completamente de acuerdo en eso, ya lo sabes ;)


Ahí sí, la tabla de atributos de sprites se puede colocar cada 1024 bytes gracias a los registros #5 y #11 y la tabla de patrones de sprites cada 2048 gracias al registro #6.

Nota: aunque en este mensaje hable de ellos, en un MSX1 los registros del VDP superiores al 7 no existen.

Uish ... a ver como te lo explico para que lo entiendas. En el modo de 1 set del ejemplo, lo que pasa es que el mismo set, el primero es "reflejado" en el set 2 y 3.

Pero cambiado dos valores del VDP (registo 4 y 3 que son los que se toquitean para el modo este) puedes hacer que en lugar de reflejar el 1 , se refleje el 2 ... o el 3. Ya tienes un cambio brutal a velocidad de unos pocos ciclos.

Pero es que además puedes tener 1 set de patron y 3 de color ... o viceversa.

En resumen, que no cambia nada de sitio, todo sigue en el mismo, pero usado de una manera diferente. Espero haberme explicado ahora. ;)



Lo se lo se. Y además apoyo totalmente ese modo si el mixto no va en todos los MSX. Modo natural y totalmente compatible.

Y la opción de ARTRAG de usarlo como espacio de almacenamiento, pues otra utilidad más. :) Utilidades hay muchísimas y se pueden hacer, como dice Jon, un montón de cosas. Pero si no va ... pues no se puede hacer ninguna (hablando de compatibilidad claro).

Me gustaria hacer un parentesis en este hilo y sin cortar el tema

Inciso:
En otro hilo, pregunté sobre el modo mixto, y aunque hubo muchas respuestas, mas que quedarme claro la cosa me quedo mas confusa, porque yo siempre habia pensado que el modo mixto era el de los tres bancos de 255, y que había que definir a gusto cada uno de los bancos. La unica información que yo tengo de esto es la que apareció en una revista de MSX-Club (no recuerdo el numero) pero que afirmaba que con dos llamadas a la Bios(una para llamar a Screen 1 y otra para llamar a Screen 2 sin modificar ninguna tabla)  se podía establecer este modo. Solo quiero que alguien me diga si esto es así, y si se puede trabajar como si fuera screen 1 pero con 8x2 colores por caracter de forma secilla como en screen 1 (que por lo que he deducido es así).
Fin del inciso:

Ajá, o sea que tienes un total de 3 bancos definidos en memoria pero tú seleccionas que sólo se vea uno de ellos. Según te entiendo, el tema es que puedes decir explícitamente cual de los tres se va a replicar en toda la pantalla. Y, además, puedes hacerlo de manera independiente para los colores y los patrones...

¿Te he entendido bien? Si es así ahora sí que le veo la ventaja al modo mixto... qué pena que sea un bug del VDP y no esté adecuadamente documentado. Encima, al parecer, no funciona correctamente en todos los MSX... Una lástima. Este finde lo probaré en mi HX-10 a ver qué hace.

Recuerdo muy bien ese artículo, ya que tecleé el listado completo que venía con él. Realmente no era el modo mixto del que hablamos aquí, ya que lo que hacía era seleccionar Screen 2 y luego hacer creer al basic que estaba en Screen 1. De forma que tenías la posibilidad de trabajar en modo texto en SC1 pero con el colorido de SC2. Además extendía las instrucciones del MSX-Basic utilizando el prefijo CMD y añadía un comando CMDTVP (si mal no recuerdo) que no era otra cosa que un triple Vpoke para modificar al mismo tiempo los tres bancos. Por cierto, funciona perfectamente en mi HX-10.

Recuerdo, además, que me metí un poco más a fondo con el modo ese y llegué a combinar gráficos en SC2 con texto en SC1. Los dos primeros tercios los utilizaba como SC2, pudiendo ejecutar comandos como LINE, CIRCLE y DRAW, mientras que el último tercio era SC1. Incluso empecé a programar un pequeño editor gráfico y todo... a saber dónde andará ::)

Por último, para los interesados, el artículo se titula "Extrascreen" y (consultando el índice de las revistas) apareció en el número 58 de la MSX-Club, páginas 20 a 26. Si la memoria no me falla el autor fue "Pau Soler i Pla" (quizá con algún acento, pero ahora no recuerdo bien ya que eso lo digo de memoria).

Ese tal Pau Soler i Pla no escribió también otro artículo sobre puro SCREEN 1?. Creo recordar que fué muy didáctico para mi en su día!

Si, eso es. :) Y no tienes porque tener los bancos llenos. Si solo usas 1, pues con rellenar ese y hacerse el "espejo" pues ya sobra. :)

Pero vamos, que todo es precioso, aunque yo ya me he hecho a la idea de que no podré usarlo. Lástima.

Ultimo inciso:

Sapphire: Pues si ese articulo es.

Lo unico que quiero saber es si con las dos llamadas a la bios que indica en el articulo, la definicion de los mismos graficos en los 3 bancos y la tabla 10 se puede utilizar el Screen 2 como un Screen1 sin mas complicaciones. Lo digo porque yo no he experimentado aun con estos modos y quiero conocer de antemano su complicacion ante de meterme en fregaos, ya que de la eleccion del modo depende el diseño de los graficos.

Me basta un si o un no.

fin del último inciso.

No problemo, si aquí estamos todos para aprender. Mira, puedes pasar completamente de modos mixtos y demás. Si usas SC2 a pelo y quieres tener un único banco para toda la pantalla, simplemente puedes volcar los mismos patrones y colores tres veces y ya estaría. Luego te olvidas de las tablas de patrones y colores y trabajas únicamente con la tabla de nombres, donde están los 768 huecos para meter cada uno de los 256 patrones que has definido.

Olvida modos raros si no vas a hacer cosas raras. Si sólo necesitas 256 patrones y colocarlos por pantalla sin problemas: SC2 volcando tres veces el mismo patrón. Es estándar, es sencillo y es compatible.


Creo recordar que sí, posiblemente sea el autor del artículo "Screen 1" de la MSX-Club 55 (páginas 37-41). Es cierto, supo transmitir muy bien los conocimientos en ambos artículos, ¿qué habrá sido de él?

Tiene narices que pa que una vez que Jon y yo coincidimos en algo, sea pa tocar las narices  :P

Si sale algo revelador avisa, y me ahorro abrir el mio  8)  Es mi pequeñin. Aunque no debe haber problema, es el unico que no he abierto aun :P

Ciertamente :) A raiz de ese articulo nacio el primer Kame Graphics (que hace uso de la rutina, o hacia, pq luego trapichee algo...) Y si que estaba bien explicado, pq realmente es algo que me quedo bastante claro, a diferencia de otras cosas.

Ha salido a mi  :)


Como he dicho, si lo abre Jon y ya vale, dejo el mio tal cual, pero si sigue haciendo falta, lo abro, que no sera dificil.


Tu diras, hara falta mapa?  :P

Un ejemplo de ese modo usado desde BASIC lo puedes encontrar, por ejemplo en este juego del concurso BASIC (aunque se usa en alguno más):

http://personal.telefonica.terra.es/web/karoshicorp/foro/basic/Memory%20Game.rar

Varias cuestiones interesantes van apareciendo en este hilo, si señor.

El asunto de usar o no este modo por sus incompatibilidades, por ejemplo.
Considero que depende mucho de como enfoques la cuestión. Para mi más que un bug del VDP, creo que se debería cosiderar como un modo no documentado, ya que las distintas versiones del chip (del  original y compatibles) y sus evoluciones lo soportan (creo que incluso el vdp de la master system, pero no lo sé seguro). Sólo una remesa de ordenadores concretos por las causas que fuesen (error de fabricación o cambio a chips no del todo compatibles) tienen un fallo que no permite ese modo. Lo veo un poco como los 8235 que tienen el fallo de memoria, no porque en esas máquinas no funcione no se han de producir programas que usen 128Ks de ram. Es decir, el error a la norma no esta en el programa, sinó en la máquina. Así lo veo yo, vamos.

Esto por el lado digamos de "filosofía de la norma MSX"; por el lado meramente práctico dudo que hoy en día nadie se quedase sin disfrutar un juego por causa de la incompatibilidad de su equipo.

Pues eso, que para mi se debería tomar como norma que es un modo legal y que alguna máquina tiene un bug (si sólo fueran esas con eso...) y que sería una pena que solo por eso no se aprovechasen sus características para los juegos que lo requiriesen.  ;)

Ya digo, es mi opinión.

un saludo.

Yo creo que todo se tendría que investigar.

Cierto es que si el modo mixto no cumple a raja tabla la norma, estoy a fabor de que no se use pero, si el problema viene por una remesa de chips diferentes y / o defectuosos...

Lo suyo sería investigar a fondo con una de esas máquinas.

Por mi parte, todavía no he podido hacer la prueba con mi hb-55p con 16kb de ram.  Básicamente el problema lo tengo en que se me ha vuelto a joder la conexión a internnet, y ahora mismo estoy con la conexión del vecino, que a duras penas me deja visitar webs y va más lento que el caballo del malo.  Ha de tener la conexión saturada bajando porno del duro, ... vamos, digo yo
A ver si insistiendo consigo bajar la rom.

Venga. un saludo

makinavaja

Ese maki, a ver si mejoras el tema de tu conexión... por cierto, pocas mofas que me estoy echando con Ebichu  :D

Ebichu RLZ!!! De hecho habrá un set de enemigos del WI dedicado a Ebichu, ¿verdad maki? Jejejejeje...

Veo que pese a asistir a la cena me perdí muchos detalles frikis! Pero sí que recuerdo la frase de SC0, con un par! Y qué fue del Ahorcado con 20.000 palabras? Al final no cabe en 32 KB?  ;)

En fin. Respecto al tema de este hilo, lo cierto es que el modo mixto es un poco como el Santo Grial: hay que creer en él y buscarlo. Lo ideal sería poder verificar que la incompatibilidad se debe al uso de un chip gráfico distinto. De todos modos, el TMS9918 es sólo una de las variantes que llevan los MSX. En la misma familia encontramos el TMS9928 y el TMS9929, compatibles a nivel funcional (pero quizás no a nivel de "bugs" :( ) y un sinnúmero de clones de todos los colores. Habría que despiezar los ordenadores en los que falla y determinar a las claras el listado de chips que petan. Así podremos ofrecerles un "upgrade" a "mixed-mode compliant chips"  ;D

No, es broma: si falla aunque sea en un único modelo de MSX, para mi no es MSX compatible, como dice Armando. Es un tema más filosófico que otra cosa. Puestos a ser prácticos, sería mejor decir que no hay tutía y que la gente se pille MSX con el chip "güeno".

Pues recuperemos el SCREEN 3, que ése sí que está infrautilizado :D

Esto ... bueno. ¿Alguno de los propietarios de los ordenadores con un TMS de mentira ha podido ver que llevan dentro?

A ver si podemos ver que chip es y buscar información técnica. Si conseguimos hacer un modo mixto funcional en esos ordenadores y en los que incorporen un TMS de verdad, pues tendríamos todo atado. Por intentarlo no perdemos nada.

Pero algo me dice que no vamos a conseguir nada.

Hoy la conexión me ha permitido bajarme la rom.  A ver si de aquí un rato hago la prueba y os digo si  va o no va en e mi hb-55p... y si no va.... operación!! (que miedo me doy aveces)


Venga, un saludo

Makinavaja

Ahórrate el esfuerzo si es una ROM y no tienes ampliado el HB-55P. Para cargar una ROM en RAM necesitas tener, como mínimo, 32 KB de RAM. Si tienes más RAM o puedes copiar la ROM en una FlashROM y eso, perfecto. Me interesa especialmente saber si todo va finito en ese modelo.

Eso Edu lo arreglamos en un please. Ahora monto un .BIN para que lo cargue con Bload si quiere. ;)

<OFFTOPIC>
Ese ahorcado con 20.000 palabras lo haré, pero antes quiero terminar el WI (ese otro juego friki en SC0, con un par!) para este fin de semana y luego me dedicaré al QBIQS, que me apetece ponerme a mejorar todo el rollo gráfico que aún no está visible :D
</OFFTOPIC>

No os preocupeis

tengo la flash de padial para probarlo

Además, puedo hacer uso de la cf-ide + 4mbRAM de padial, con eso hasta me conecto a internet con inl y rs-232 XD

Venga, os digo algo en breve

Saludos

Makinavaja

Buenas de nuevo

Acabo de probar la rom, y en mi hb-55p funciona, se ven los tres recuadros.  Las pruebas las he hecho con el cartucho flash de padial :)

Bueno, si necesitáis alguna otra prueba, aquí me tenéis

Saludos


Makinavaja

Si esta visto que toda la gente malvada tira de VDPs de alto standing.... no es justo.  >:(

Pero no digas de mentira  :'( :'( :'( Finolis na mas.... scrms:)

Esto... yo como lo iba a hacer Jon, pos no he hecho na, pero aun asi lo dejo pal finde que es cuando tendre algo de tiempo pa eso y pa probar la ROM en el Philips y el Panasonic (q, ademas este ultimo ya esta medio abierto y todo... )

Yo discrepo, pero respeto si lo veis así.

Un saludo,

Salva

Bien, acabo de abrir el SONY HB-10P  2gf:)

Cual fué mi sorpresa al encontrar que el VDP es un Toshiba T6950, chip supuestamente compatible con el TMS9929A y que de forma más habitual... ¡aparece montado en los MSX Toshiba HX-20!.

¿Este descubrimiento podría ser determinante para corroborar incompatibilidades?. Sería interesante que alguien con un Toshiba HX-20 hiciera una prueba con la demo, o que el Kun nos confirme cuál es el chip de video de su máquina... si su VDP es también un T6950 se haría cada vez más real la teoría la incompatibilidad en ciertas máquinas con nuestro denominado modo mixto :'(

Creo que WYZ tiene uno... Yo abriré el HX-10 a ver qué me encuentro, además tengo dos (uno que funciona y otro que no), así que podré comprobar ambos... pero eso será esta tarde :D

Así pues, la hipótesis (a) gana fuerza: los fabricantes usaron lo que tenían más a mano, y como los chips son compatibles a nivel de patillaje, pues tanto daba poner uno como otro. El problema es que ciertas características no documentadas del TMS9919 no se dan en algunos clónicos.

¿Qué hacer? Vosotros diréis.

Pues yo creo que se cumple mi teoría, que es cosa de los MSX.

Efectivamente, todo apunta hacia esa dirección :'(

Mil gracias Jon por probarlo.

Pues nada. Solo quedan algunas opciones. Buscar el datasheet de esos VDP y sobre todo hacer pruebas con ellos para ver si es posible conseguir ese modo de alguna manera. Yo como dice Edu, creo que va a ser imposible y personalmente me olvido para siempre de ese modo en MSX1.

La razón de usar esos chips es clara. Supongo que les saldrían más baratos y cumplen al 100% todos los detalles de la norma. Así que no hay que culparles por ello.

Pues nada, casi mejor que abrimos otro hilo y pensamos como implementar según que cosas que teníamos pensadas con este modo mixto de la manera más eficiente posible.

Bueeeeno, mañana (o esta noche si no salgo) abro el mio, a ver q tiene dentro.
Como haya un Toshiba de esos, voy a Sony con el y pido que me lo cambien (el vdp) por timadores!!! Colaria?  :P

Si, yo tengo un HX-20, SD- Snatcher tambien, uno de los MSX con mas pegas, si no el que mas. EL VDP, el PSG, la memoria en incluso el patillaje del slot de cartucho no son del todo "compatibles". Haré mañana esa prueba, pero ya adelanto que solo se ve el 1er set en este modo hibrido.

(http://www.msxgamesbox.com/karoshi/forum/hb10p_01.jpg)

(http://www.msxgamesbox.com/karoshi/forum/hb10p_02.jpg)

(http://www.msxgamesbox.com/karoshi/forum/hb10p_04.jpg)

¿Será ésta la foto del culpable?. Kun, si encuentras este VDP en tu HB las cosas estarán ya más claritas...  :)

pues chútale uno de estos!!!

Es broma...
Estoy muy tenso, ya  tengo internet, pero he pasado una mala mañana....
luego reaparezco por estos lares.... Necesito calmarme un poco.

Enga

Saludos

Encontrado :( Es ese mismito.

Y tb he probado en el Philips 8020 y el Panasonic CF 2700 y en ambos acepta el modo mixto sin problemas. He abierto el Panasonic tb, pero no he visto el chip, hay mucha placa dentro.

¡Míralo al puñetero, que clarito se ve!. Si no me equivoco el condenado además tiene un patillaje diferente, por lo que no valdría que los usuarios manitas montaran un zócalo y lo cambiaran por un TMS. Un faena...

He buscado el datasheet y no hay tu tía no lo encuentro por ningún lado. Lo único que se me ocurre es experimentar algo más con los registros y configuración de la VRAM, a ver si se puede conseguir algo parecido. :(

Venga sigamos con las fotos. :)

Es que creo que el problema es la versión de ese VDP, no que sea de Toshiba o no. Mirad, he abierto el HB20 donde si va.

Seguro que en el de KUN está la misma versión que en el de Jon.

Vaya, pues esto complica mas las cosas no?  ???

Pues igual es cuestión de buscar por ahí T6950A's y el que pueda pegarle el cambiazo que se lo pegue. Aunque eso no solucionaría el problema de que sigan quedando usuarios que no puedan disfrutar de los juegos programados en ese modo... :(

Acabo de abrir uno de los HX-10 que tengo y el VDP está completamente borrado, todo en negro. Ahora no tengo tiempo de abrir el otro (que es el que funciona), lo haré a lo largo de la semana y os comentaré qué tipo de VDP tiene y si funciona la demo en él o no.

Una pregunta ... igual tonta .. pero ... que ventajas tiene el Modo Mixto este .. con respecto al Screen 1 normal?

Pues en ese caso es mucho más difícil de diagnosticar en que máquinas puede fallar o no. Entonces, llegados a este punto... ¿Pure Modes are our friends o que?  :-\

Lo digo .. porque según el MSX2-Tech HandBook .. el Screen 1 NORMAL .. tiene PCT (Pattern Colour Table) .. vamos que no se que tiene de especial el Modo Mixto. Si alguién puede aclararme esto. Gracias.

SCREEN1 tiene solo un banco de patrones, si, pero el tema de color es bastante más chungo... verás, sólo puedes tintar los caracteres en grupos de 8, es decir, que cada 8 caracteres deben tener el mismo atributo de color: pero no solo eso, sino que dicho patrón de color solo puede tener la información de dos colores por cada caracter (es decir, tinta y fondo, nada de 2 colores por byte).

Haz una prueba de campo, que lo verás mejor. Escribe en BASIC:

SCREEN1: VPOKE 8204,&h81

Verás como, de pronto, los caracteres <´abcdefg> cambian su color y se ponen rojos con negro de fondo. Es decir, con un byte modificamos el color de 8 caracteres, así pues los atributos de color para SCREEN 1 tan solo ocuparán 32 bytes.

Si puedes vivir con esas desventajas, SCREEN 1 no está tan mal, teniendo en cuenta que se pueden usar sprites. Para ejemplos de juegos actuales de SCREEN 1 puedes probar "Los Jardines de Zee Wang Zu" de Jos'b o el ingame del "Factory Infection" de Karoshi Corp.

... aunque donde esté SCREEN 2...  ;)

Pure mode. No hace falta nada más para realizar grandes programas. :)

Si bueno.. yo hasta ahora he sido muy feliz con el Screen 2 ... al mirar así por encima lo del Screen 1 .. me quede un poco pillado al ver que tenia Color Table. Vale, está claro que tiene esa limitación .. sin dudas me sigue molando más el SCR2.
Aunque me da que el MSX-1 no está pensado para scrolls demasiado suaves en Screen 2, cierto es que no los considero en absoluto necesarios, aunque pueda a sonar a rendición :-)
Otra pregunta .. el VDP tiene algún flag chungo por ahi .. que NO APAGUE la pantalla pero SI APAGUE el Dibujado?

Esto ... ¿podrías explicarte un "pelín" mejor?

¿Qué es lo que quieres hacer?

Pues eso mismo.. no quiero APAGAR la pantalla .. pero si quiero Meter datos en la VRAM .. y para que no se me vea el plumero quiero que el VDP no dibuje nada y se esté quietecito.

Pues pa mi que no se puede. Como mucho puedes esperar al VBlank donde tienes un tiempo donde meter datos sin que el VDP haga nada, hasta que empiece a rasterizar el siguiente frame.

Imagino que tu problema es que son un montón de datos.

Si bueno .. creo que es el problema de casi todos .. poder meter datos a tutiplein sin que se vea la cosa. Pero bueno .. yo por preguntar .. me imaginaba que no se podría. Cachis! :-) .. seguro que si escribes 0xFF en todos los registros del VDP no pasa esto? :D jejejeje .. pa mi que hay features ocultas en los VDP.

Hombre, como poder puedes hacerlo. El problema es temporizarlo bien para que no se note ni a 50 ni a 60 y en todos los VDP. Puedes empezar a escribir los datos al revés, de abajo a arriba... aunque te puedes "cruzar" con el rasterizado y que se te note el parpadeo arriba.

O puedes ser más rápido que instantáneo e ir por delante del raster ...

Seguro que si te lo organizas bien puedes hacerlo.

 

Podrías tener una forma utilizando dos tablas de nombres, la normal en $1800 (vdp#2=6) y otra en $1C00 (vdp#2=7). Si redefines con cuidado y lo organizas bien, conmutando las páginas puedes obtener ese resultado que buscas.

Bueno .. yo es que queria hacer cosas más bestias .. como modificar las 3 PGT .. o sea 2048 Bytes * 3 por frame .. me da que eso choca con el raster casi que seguro.

De "casi" nada...  ;)

Te lo juro por Snoopy...

Y yo por la cobertura de mi móvil...

Creo que es un buen momento para hacer un DIIIIIII HAAAAAAAAAAAAAAAAAAAAAAALT!  :D

Llego tarde al thread, pero bueno.

A continuacion os voy a poner la conclusion a la que llegamos varias personas cuando vimos este tema:


El 9918 de toshiba solo te muestra un set de patrones.
Creo que el 9928 de Yamaha (no me hagais mucho de cual era exactamente) tenia problemas con los sprites (duplicaba los sprites del 8 al 31)
Parece que en el resto de VDP msx1 funcionaba bien.

El 9938 y 9958 funcionaban perfectamente

Ya podrías haberlo dicho antes, y nos hubieses ahorrado un montón de mensajes. :P

En fin, que bueno, que a ver si te vemos más el pelo, pero en formato software y tal... :)

Bueno, pues hoy (que ya estoy de vacaciones por fin) he podido probar algo en mi HX-10. Al parecer NO soporta el modo mixto, ya que el Stratos, juego que lo usa, no funciona correctamente. He hablado con WYZ y me ha dicho que, efectivamente, utiliza ese modo, pero que en su HX-20 funciona sin problemas. Si alguien más pudiera probarlo en un HX-10 sería de agradecer, para saber si el problema es genérico de este modelo o del mío (y algunos más) en concreto.

De todas formas yo no voy a usar el modo mixto, porque si lo uso no podré jugar en mi propio ordenador... :-\

Saludos!!
--
Sph.