MiSTer FPGA: Plataforma que implementa Consolas clásicas, microordenadores y arcades

GXY escribió:

AlterNathan escribió:@GXY Pero lo de cambiar en caliente ya se hace, ¿No? Yo estoy en el core de Megadrive y puedo cambiar al de SNES sin necesidad de resetear la MiSTer. Porque cambiar de juego sería técnicamente cambiar de core pero de otra manera.

Lo digo con toda la ignorancia del mundo claro está xD.

Saludos.

me parece que si reseteas la mister para cambiar de core

lo que cambia en mister (creo) es que se puede reiniciar el FPGA sin reiniciar completamente la maquina (el arm no se apaga y con el es con el que eliges core).

que un usuario confirme.

No hace falta resetear, es decir, con un core activo puedes elegir otro directamente y la máquina se reconfigura sola. No es necesario un reseteo previo.

Un saludo.

GXY escribió:yo lo veo ok para integrar mas sistemas, principalmente arcades que se queden fuera de los cores que se vayan desarrollando. el problema de los arcades es que como muchos son de su padre y su madre "en terminos de plataforma" (muchos de ellos no son plataformas homogeneas como un ordenador o una consola), eso dificulta y hace dificilmente abarcable la tarea de que muchos "lleguen a mister".... pero luego los usuarios percibimos "arcades" como una sola "plataforma" (de hecho muchos trasponen "MAME", el multiemulador, como si fuera un "sistema"), lo cual facilita que, por ejemplo, para alguien que viene de tener una raspberry, perciba que "mister tiene pocos juegos de mame" (y seguro que esta burrada que acabo de escribir, alguno ya se la ha encontrado )

Meter emuladores rompe la filosofía totalmente, y cuestiona muchas cosas; pero allá ellos. No lo tendrán muy claro tirando solo de FPGA, y les parecerá estar desperdiciando el ARM.

Pero igual que tú, por mi parte lo veo OK, porque me parece bien que se rompan las ideas cerradas a cambio de otras más integradoras y versátiles.

Hablando de arcades, ¿sabéis si se está trabajando o hay al menos interés en la PolyGame Master? Siempre me hizo gracia esa especie de neo-geo taiwanesa y por compenentes supongo que no habría problema en implementarla en la mister.

@Sema81 La primera Poly puede ser, y quizás la segunda pero la tercera tengo dudas.

Saludos.

_Seagal_ escribió:

MAME internamente es un multiemulador. es decir, que "dentro" tiene muchos emuladores diferentes (de diversos procesadores, otros integrados, etc).

implementar eso en FPGA (es decir, que en la FPGA coexistan, a la vez, las implementaciones de muchos procesadores y otros integrados, y que luego en funcion del juego se utilicen unos u otros) necesitaria un procesador con muchas mas de 110mil celdas, o reconfigurarlo cada vez que se ejecuta un juego, lo cual seria mas plausible, pero tampoco se ha hecho nunca (esa configuracion se hace al encender/cargar core y al reiniciar la maquina. no se hace "en caliente").

yo no lo veo como un "port del mame", sino un "mame version fpga" que parece lo mismo pero no. y ya digo... que que yo sepa no se ha hecho nunca. y como minimo necesitaria "reiniciar el sistema cada vez que se cambia el juego" para "cambiar el core" (reconfigurar el FPGA).

creo que no me he explicado bien. Me referia a un port del mame para el arm que tiene la mister, y que se pudieran escoger los procesadores implementados en fpga, del mismo modo que ahora se pueden escoger varias implementaciones en emulacion del mismo procesador (el startscream en asm, el normal en c... ).

Por ejemplo, el out run, utiliza dos 68000, a parte de otras tantas cosas, y sabemos que en el mister hay espacio para esos dos 68000 porque la megadrive con el megacd ya son esos dos procesadores, pues seria el core del system16 del mame rulando todo por soft menos esos dos procesadores que irian por 'hard'.

creo que algo parecido a eso es lo que van a hacer

pero, si por ejemplo, saltas de outrun que utiliza dos 68000 a... yo que se... otro juego que necesite otro procesador que no sea el 68000 y no "quepa" con lo anterior, pues hay que reconfigurar la FPGA. que si se puede hacer durante el "arranque", pues guay.

en ese caso, seria una especie de "raspberry vitaminada" ya que algunas cosas las haria el ARM y otras, la FPGA.

no es un mal metodo, ni mucho menos.

GXY escribió:

Hodor escribió:[...]

yo lo veo ok para integrar mas sistemas, principalmente arcades que se queden fuera de los cores que se vayan desarrollando. el problema de los arcades es que como muchos son de su padre y su madre "en terminos de plataforma" (muchos de ellos no son plataformas homogeneas como un ordenador o una consola), eso dificulta y hace dificilmente abarcable la tarea de que muchos "lleguen a mister".... pero luego los usuarios percibimos "arcades" como una sola "plataforma" (de hecho muchos trasponen "MAME", el multiemulador, como si fuera un "sistema"), lo cual facilita que, por ejemplo, para alguien que viene de tener una raspberry, perciba que "mister tiene pocos juegos de mame" (y seguro que esta burrada que acabo de escribir, alguno ya se la ha encontrado )

Ahora mismo hay muchos arcades dentro de Mister que se desarrollan en torno a una plataforma concreta. Por ejemplo, CPS1, System 1 o el muy reciente Irem M62. Algo muy lógico porque comparten hardware y cuya misma filosofía también se sigue dentro de MAME.

Pero el abanico de hardware es tan inmenso que acercarse al nivel de este último probablemente requiera de años sólo para los más clásicos de los 70, 80 y 90. Y eso suponiendo que haya gente con ganas y conocimientos -por el momento así ocurre.

_Seagal_ escribió:[...]

creo que no me he explicado bien. Me referia a un port del mame para el arm que tiene la mister, y que se pudieran escoger los procesadores implementados en fpga, del mismo modo que ahora se pueden escoger varias implementaciones en emulacion del mismo procesador (el startscream en asm, el normal en c... ).

Por ejemplo, el out run, utiliza dos 68000, a parte de otras tantas cosas, y sabemos que en el mister hay espacio para esos dos 68000 porque la megadrive con el megacd ya son esos dos procesadores, pues seria el core del system16 del mame rulando todo por soft menos esos dos procesadores que irian por 'hard'.

Yo esto lo veo un despropósito, sinceramente. Entonces, ¿para qué estamos dando la tabarra día sí y día también sobre la supuesta superioridad tecnológica de las FPGAs frente a la emulación por software si luego seguimos utilizando ésta y encima dentro de una plataforma ARM muy limitada? Para eso no me compro una FPGA, me quedo con el PC y todos felices.

O se aprovechan las ventajas de las FPGAs en cuanto a replicación del hardware dentro del contexto en el cual nos movemos o pierden completamente su sentido. No sólo ya pensando en el disfrute de una plataforma concreta sino también para algo tan importante como la preservación de hardware con décadas a sus espaldas.

Un saludo.

_Seagal_ escribió:

MAME internamente es un multiemulador. es decir, que "dentro" tiene muchos emuladores diferentes (de diversos procesadores, otros integrados, etc).

implementar eso en FPGA (es decir, que en la FPGA coexistan, a la vez, las implementaciones de muchos procesadores y otros integrados, y que luego en funcion del juego se utilicen unos u otros) necesitaria un procesador con muchas mas de 110mil celdas, o reconfigurarlo cada vez que se ejecuta un juego, lo cual seria mas plausible, pero tampoco se ha hecho nunca (esa configuracion se hace al encender/cargar core y al reiniciar la maquina. no se hace "en caliente").

yo no lo veo como un "port del mame", sino un "mame version fpga" que parece lo mismo pero no. y ya digo... que que yo sepa no se ha hecho nunca. y como minimo necesitaria "reiniciar el sistema cada vez que se cambia el juego" para "cambiar el core" (reconfigurar el FPGA).

creo que no me he explicado bien. Me referia a un port del mame para el arm que tiene la mister, y que se pudieran escoger los procesadores implementados en fpga, del mismo modo que ahora se pueden escoger varias implementaciones en emulacion del mismo procesador (el startscream en asm, el normal en c... ).

Por ejemplo, el out run, utiliza dos 68000, a parte de otras tantas cosas, y sabemos que en el mister hay espacio para esos dos 68000 porque la megadrive con el megacd ya son esos dos procesadores, pues seria el core del system16 del mame rulando todo por soft menos esos dos procesadores que irian por 'hard'.

Poder yo creo que se podríaennlas maquinas que lo cabieran por fpga y si una parte, igualmente creo que esto es un pez que se muerde La cola y cada vez están saliendo más arcades porque tienen que aprovechar el trabajo ya hecho..(jotego de 1 semana a otra te saca uno diferente )

Comprarse una FPGA (con procesador incluido) para usarla con emuladores por software es como comprarse un ferrari para usarlo de taxi .

Que si, claro que van a realizar la funcion esa. Pero sentido tener tiene poco, ademas de ser un desperdicio de tiempo y dinero .

Que no me parece mal que lo hagan opcional, vamos que otros desarrolladores lo implementen a parte y el que lo quiera que se lo instale y asi todos contentos. Pero meterlo con el oficial, que sorgelig y compañia pierdan tiempo en su desarrollo y mantenimiento me parece una soberana estupidez .

Lo siguiente que van a pedir algunos va ser un media center integrado para poder ver el netflix en la mister... sino tiempo al tiempo xD.

Pero ahora mismo creo que ya se está haciendo , es decir que se están utilizando códigos de Mame para complementar los cores ya que hay mucho trabajo de muchos años hecho y facilita la faena , me pareció leer algo de esto en el lanzamiento del contra de jotego aunque si que es cierto que es una primera beta

Hodor escribió:Yo esto lo veo un despropósito, sinceramente. Entonces, ¿para qué estamos dando la tabarra día sí y día también sobre la supuesta superioridad tecnológica de las FPGAs frente a la emulación por software si luego seguimos utilizando ésta y encima dentro de una plataforma ARM muy limitada?

a lo mejor parte del problema ha sido precisamente ese "exceso de tabarra"

tanto un metodo como otro como los que puedan haber son "simples" herramientas. el objetivo (creo yo) al final, es jugar. (lo mejor posible) y creo que contar con dos herramientas supone una ventaja, no una desventaja.

edit. lo de usar trabajo hecho en emulacion para "adelantar tarea" con la implementacion de cores en FPGA ya dije hace paginas que se hacia. el que se rasgue las vestiduras por ello, allá él.

vtec16 escribió:Pero ahora mismo creo que ya se está haciendo , es decir que se están utilizando códigos de Mame para complementar los cores ya que hay mucho trabajo de muchos años hecho y facilita la faena , me pareció leer algo de esto en el lanzamiento del contra de jotego aunque si que es cierto que es una primera beta

Jotego dice, cito textualmente:

En cuanto al juego en sí, he respetado la arquitectura original de dos chip gráficos. Aunque el contenido de este chip no se ha detallado aun y por tanto he hecho una reconstrucción en base a cómo está conectado, lo que se sabe por MAME y medidas en la placa

Lo cual es un paso lógico mientras no se conozca con exactitud qué hay detrás de ambos chips propietarios. Y esto ocurre no sólo con este caso concreto sino con otros igualmente. Todo ello muestra asimismo que las FPGAs no son 100% fieles hasta que no se conozca en detalle cada circuito integrado de aquello que pretende replicar, algo que ya he comentado por aquí en más de una ocasión.

La versión del Contra de Jotego probablemente sea superior a la del MAME, entre otras cosas porque implementa su extraordinaria simulación del Yamaha YM2151, pero se ha visto forzado a utilizar la documentación existente porque decapar un chip y analizarlo de manera que pueda ser replicado requiere de un trabajo muy especializado y extenso, quizás fuera del alcance de una sola persona. No le ha quedado otro remedio al igual que ocurrirá con otros arcades.

GXY escribió:

Hodor escribió:Yo esto lo veo un despropósito, sinceramente. Entonces, ¿para qué estamos dando la tabarra día sí y día también sobre la supuesta superioridad tecnológica de las FPGAs frente a la emulación por software si luego seguimos utilizando ésta y encima dentro de una plataforma ARM muy limitada?

a lo mejor parte del problema ha sido precisamente ese "exceso de tabarra"

tanto un metodo como otro como los que puedan haber son "simples" herramientas. el objetivo (creo yo) al final, es jugar. (lo mejor posible) y creo que contar con dos herramientas supone una ventaja, no una desventaja.

edit. lo de usar trabajo hecho en emulacion para "adelantar tarea" con la implementacion de cores en FPGA ya dije hace paginas que se hacia. el que se rasgue las vestiduras por ello, allá él.

Creo que ya conoces mi postura sobre los emuladores y las FPGAs, por tanto estoy de acuerdo con lo que dices. En lo que discrepo es en la mezcla de ambos mundos, no tanto porque sea algo malo en sí mismo, sino porque profundizar en la réplica mediante lo segundo permite preservar un hardware que de otra manera se perderá para siempre y, además, la emulación por software también se verá beneficiada. Es decir, uno y otro ámbito se complementan.

Sin embargo, utilizar emulación por software en una réplica FPGA le quita buena parte del sentido a esta última. Como bien comenta @jimi, mucho mejor dedicar el trabajo y el esfuerzo a un sólo camino aunque tarde más tiempo. El resultado final, siempre y cuando pueda completarse satisfactoriamente, siempre ofrecerá mejores recompensas aunque sólo sea, repito, por pura preservación.

Un saludo.

Ante la imposibilidad en muchos casos de decapar cada a chip a un tamaño adecuado para analizarlos al 100%, si resulta que se está aprovechando el trabajo en emulación para crear los cores FPGA, eso quiere decir que el trabajo de preservación del hardware comienza y continua desde la emulación, siendo la implementación en FPGA la materialización en físico de ese trabajo.

O sea, que la tecnología FPGA en sí ni es la única ni es la principal que preserva hardware, porque el trabajo de preservación ya lleva décadas haciéndose. Las FPGA vienen para seguir materializando ese trabajo en otro proyecto complementario al de la emulación.

Si resulta que una placa FPGA para implementación tiene capacidad para tirar también de emulación, con buen resultado, no veo por qué no aprovecharlo; al fin y al cabo, se supone que al final será el usuario quien decida si hacer uso de ello o no.

gynion escribió:Ante la imposibilidad en muchos casos de decapar cada a chip a un tamaño adecuado para analizarlos al 100%, si resulta que se está aprovechando el trabajo en emulación para crear los cores FPGA, eso quiere decir que el trabajo de preservación del hardware comienza y continua desde la emulación, siendo la implementación en FPGA la materialización en físico de ese trabajo.

O sea, que la tecnología FPGA en sí ni es la única ni es la principal que preserva hardware, porque el trabajo de preservación ya lleva décadas haciéndose. Las FPGA vienen para seguir materializando ese trabajo en otro proyecto complementario al de la emulación.

Si resulta que una placa FPGA para implementación tiene capacidad para tirar también de emulación, con buen resultado, no veo por qué no aprovecharlo; al fin y al cabo, se supone que al final será el usuario quien decida si hacer uso de ello o no.

correcto.

tambien significa que esa implementacion FPGA no se basa en la electronica original, sino en la interpretacion de la misma que se hace en la emulacion, con lo cual es tan fiel como lo sea dicha emulacion.

esto lo digo para que conste y quede claro, teniendo en cuenta ciertos comentarios que he leido en este hilo anteriormente.

El plus que otorgan las FPGA es el que el paralelismo viene de serie, no hay que acomodarlo como en el software. Esto abre muchas puertas para crear cores más cercanos al hardware original.

Al final si crean una cpu por fpga basándose en el Mame será una cpu igualmente que bien se podría construir o hacer un asic, la emulación también construye o simula hardware a su manera.

Hasta las propias compañías sacan versiones de chips baratas que poco tienen que ver internamente con las originales,

Y sobre meter emuladores por que si para ampliar el catalogo de la mister lo veo fatal.
Si que vería bien por ejemplo quienes usaran partes del arm para hacer una fpu más potente en amiga o 486, usar la GPU del arm para aceleración 3d e implementar la vodoo , arm + fpga para sumar fuerzas en caso de que no quepa todo en la mister.

Cobraría más sentido de esta forma una fpga pciexpress conectada al pc...

Correr MAME con emulador hoy en día lo haces con una cafetera.

Si uno se compra la Mister es para lo que es, simulación de hardware.

No entiendo el dilema de solo hacer implementaciones por FPGA. Te pones una raspi/thinclient/futro/cacharro cualquiera al lado para lo demás y a correr.

GXY escribió:correcto.

tambien significa que esa implementacion FPGA no se basa en la electronica original, sino en la interpretacion de la misma que se hace en la emulacion, con lo cual es tan fiel como lo sea dicha emulacion.

esto lo digo para que conste y quede claro, teniendo en cuenta ciertos comentarios que he leido en este hilo anteriormente.

Y en el caso de decapar chips fisicamente, es que también se puede trasladar esa información a la emulación; o sea, que todo está vinculado de forma natural, y desvincularlo es lo artificial.

Otra de las ventajas de que Mister pueda usar emuladores opcionalmente es que desde el mismo mismo aparato FPGA se pueden comprobar las supuestas diferencias entre emulación por soft e implementaciones FPGA, para ver si por ejemplo ese input lag o el sonido que dicen es debido al sistema fpga en sí o bien a otras características de la plataforma, de las que también se beneficie la emulación.

gynion escribió:

GXY escribió:correcto.

tambien significa que esa implementacion FPGA no se basa en la electronica original, sino en la interpretacion de la misma que se hace en la emulacion, con lo cual es tan fiel como lo sea dicha emulacion.

esto lo digo para que conste y quede claro, teniendo en cuenta ciertos comentarios que he leido en este hilo anteriormente.

Y en el caso de decapar chips fisicamente, es que también se puede trasladar esa información a la emulación; o sea, que todo está vinculado de forma natural, y desvincularlo es lo artificial.

Otra de las ventajas de que Mister pueda usar emuladores opcionalmente es que desde el mismo mismo aparato FPGA se pueden comprobar las supuestas diferencias entre emulación por soft e implementaciones FPGA, para ver si por ejemplo ese input lag o el sonido que dicen es debido al sistema fpga en sí o bien a otras características de la plataforma, de las que también se beneficie la emulación.

No tiene absolutamente nada que ver el codigo de la emulacion y como funciona a como funciona el aparato real o una implementacion en FPGA.
Lo unico que se comparte es documentacion, el como funciona el sistema. Para que en el caso de emulacion por software se intente asemejar el comportamiento de entradas/salidas lo maximo posible al sistema original (o al juego en concreto que se este emulando). De hecho es muchisimo mas complicado y complejo implementar un emulador por software de un sistema que hacer una implementacion FPGA teniendo en ambos casos la documentacion del sistema y aun mas complicado que no haya bugs o diferencias.

Yo creo que mucha gente os lo tomais como si fuera algo religioso o no se. Me parece perfectamente valido y correcto que el que quiera meta emuladores en la MiSTer y quien dice emuladores lo mismo con aplicaciones homebrew o un media center.... pero lo que no veo normal es que oficialmente se de soporte a todo eso, que se intente perder el tiempo en cosas que para la mayoria de gente no tienen nigun sentido (que el que las quiera tiene otras opciones muchisimo mas baratas y con mucho mejor soporte del que va tener en MiSTer jamas).

Me parece bien que se usen implementaciones basadas en los descubrimientos de la comunidad en algunos chips de los que aun no se tiene documentacion oficial o decapado del chip ya que al final es como tener el hardware original con ese chip distinto en su implementacion pero que usa el mismo interface con el sistema y es compatible (o no al 100% aun). En el momento que se haga un decapado pues se sustituye por la implementacion real y listo, pero mientras no hay otra opcion mejor pues es una solucion valida.

@jimi
El asunto de decapar chips lo conozco por Byuu (o Ares, ahora), que publicó un artículo sobre ello, dando indicaciones de cómo sería un escaneo óptimo de los PPU de SNES, creo recordar. Como bien es sabido, él es el dev del BSNES, y a él le interesaba mucho esa información para implementar en su emulador. Si fuera tan y tan diferente, y no estuviera relacionado, ni los cores que se implementan en fpga se basarían en el trabajo que se ha ido realizando todos estos años en emulación, ni por supuesto la Mister le daría soporte directamente a emuladores, porque no podría al ser cosas tan diferentes.

Religión = Filosofía cerrada a un dogma. Me tendrás que explicar dónde está la semejanza religiosa en lo que he dicho, porque creo que de hecho defiendo lo contrario, que haya flexibilidad para lo que cada uno quiera hacer, y en ello incluyo a los desarrolladores oficiales o no de Mister.

¿Quién se está currando esos emuladores o cores fpga? pues el que se los curre que haga lo que quiera. En tu caso, simplemente te parece mal que no se centren en cores fpga, mientras que en el mio me parece bien que hagan lo que quieran, teniendo en cuenta la situación actual. Si la Mister ya hace cosas impresionantes por fpga no deberías tener prisa. Si yo fuera usuario de Mister, con Neo-geo ya me daría con un canto en los dientes (y de hecho por eso sigo el hilo, no por otra cosa).

simula la antigua psp original?

cr0nos8797 escribió:simula la antigua psp original?

No, y probablemente nunca lo haga.

Un saludo.

Hodor escribió:

cr0nos8797 escribió:simula la antigua psp original?

No, y probablemente nunca lo haga.

Un saludo.

Gracias por la info! es una pena.

Hay algún sistema de simulación por hardware? o solo hay emuladores por software? es solo por curiosidad!
le tenía mucho cariño a esa consola

gynion escribió:@jimi
El asunto de decapar chips lo conozco por Byuu (o Ares, ahora), que publicó un artículo sobre ello, dando indicaciones de cómo sería un escaneo óptimo de los PPU de SNES, creo recordar. Como bien es sabido, él es el dev del BSNES, y a él le interesaba mucho esa información para implementar en su emulador. Si fuera tan y tan diferente, y no estuviera relacionado, ni los cores que se implementan en fpga se basarían en el trabajo que se ha ido realizando todos estos años en emulación, ni por supuesto la Mister le daría soporte directamente a emuladores, porque no podría al ser cosas tan diferentes.

Religión = Filosofía cerrada a un dogma. Me tendrás que explicar dónde está la semejanza religiosa en lo que he dicho, porque creo que de hecho defiendo lo contrario, que haya flexibilidad para lo que cada uno quiera hacer, y en ello incluyo a los desarrolladores oficiales o no de Mister.

¿Quién se está currando esos emuladores o cores fpga? pues el que se los curre que haga lo que quiera. En tu caso, simplemente te parece mal que no se centren en cores fpga, mientras que en el mio me parece bien que hagan lo que quieran, teniendo en cuenta la situación actual. Si la Mister ya hace cosas impresionantes por fpga no deberías tener prisa. Si yo fuera usuario de Mister, con Neo-geo ya me daría con un canto en los dientes (y de hecho por eso sigo el hilo, no por otra cosa).

Te estoy explicando que la implementacion en HDL como en las FPGAs y la implementacion en software de los emuladores no tienen absolutamente nada que ver, ni una sola linea de codigo se va a compartir o servir de uno al otro. Lo que se comparte y es lo interesante es toda la documentacion de como funcionan los sistemas.

Si se decapa un chip o se consigue documentacion de como esta hecho internamente (o se deduce como podria estar por como funciona externamente), esa informacion es la importante. No importa el como se programe en software un emulador para simular ese sistema.

Usar recursos en mantener unos emuladores por software en vez de aprovecharlos en mantener y desarrollar los cores FPGA es un atraso, y mas cuando desarrolladores software hay a patadas y desarrolladores FPGA hay muy muy pocos. Es una mala optimizacion de los recursos humanos de que se dispone se mire por donde se mire.
Como ya dije el que quiera emuladores que los meta, que desarrolladores por software capaces para ello seguro que hay a patadas, pero no le pidamos a los pocos que hay FPGA que pierdan su valioso tiempo en esas cosas. Y no es solo retrasarles el desarrollo de cores (que es lo de menos), es que esos tios van a llegar a un punto que se van hartar y mas si les exigimos aun mas trabajo y de mantenimiento (que es ademas lo menos interesante). Y el dia que se harten a ver cuantos aparecen con el conocimiento necesario y las ganas para tomar el relevo...

Es que teneis montones de proyectos de emuladores y montones de sistemas mucho mas baratos, mas potentes, y con muchisimo mas soporte detras si los quereis. No veo esa necesidad de meter emuladores o media centers en un sistema mas caro, menos potente (a nivel de procesador, memoria, etc) y con infinitamente peor soporte... si alguien me lo explica pues bienvenido sea, porque yo no lo entiendo.

cr0nos8797 escribió:

Hodor escribió:

cr0nos8797 escribió:simula la antigua psp original?

No, y probablemente nunca lo haga.

Un saludo.

Gracias por la info! es una pena.

Hay algún sistema de simulación por hardware? o solo hay emuladores por software? es solo por curiosidad!
le tenía mucho cariño a esa consola

Verás, las FPGAs tienen una capacidad máxima que limita la cantidad y complejidad de la electrónica que pretende simular/replicar. Es decir, en el caso concreto de la Mister una consola relativamente compleja como la PSP original muy probablemente no quepa. Algo bastante complejo como la Sega Dreamcast o la Playstation 2 definitivamente no entra.

Y luego conviene tener en cuenta que, aparte de lo anterior, alguien debe de programar y desarrollar esa adaptación. Puede ocurrir que por su complejidad nadie quiera/sepa abordarla, o por simple falta de interés.

Un saludo.

Yo personalmente la Mister la veo para eso, para ser lo mas fiel posible al sistema original. Tampoco me opongo a que hagan emuladores, que cada uno la use como quiera está claro, aunque para emular ahora mismo una raspi con el rgbpi va de sobra...

Yo con lo que estoy encantado con la Mister es con el sonido del core de Amiga... Es brutal como suena en unos buenos altavoces o cascos

KKnot escribió:[...]

Yo con lo que estoy encantado con la Mister es con el sonido del core de Amiga... Es brutal como suena en unos buenos altavoces o cascos

En comparación con un Amiga 500 suena "demasiado bien". Es decir, más brillante y nítido, lo cual no termina de encajarme del todo por falta de costumbre.

Por el contrario, la calidad de imagen utilizando una tele de tubo simplemente maravillosa. Indistinguible en este caso del A500 por RGB.

Un saludo.

jimi escribió:Te estoy explicando que la implementacion en HDL como en las FPGAs y la implementacion en software de los emuladores no tienen absolutamente nada que ver, ni una sola linea de codigo se va a compartir o servir de uno al otro. Lo que se comparte y es lo interesante es toda la documentacion de como funcionan los sistemas.

Si se decapa un chip o se consigue documentacion de como esta hecho internamente (o se deduce como podria estar por como funciona externamente), esa informacion es la importante. No importa el como se programe en software un emulador para simular ese sistema.

Usar recursos en mantener unos emuladores por software en vez de aprovecharlos en mantener y desarrollar los cores FPGA es un atraso, y mas cuando desarrolladores software hay a patadas y desarrolladores FPGA hay muy muy pocos. Es una mala optimizacion de los recursos humanos de que se dispone se mire por donde se mire.
Como ya dije el que quiera emuladores que los meta, que desarrolladores por software capaces para ello seguro que hay a patadas, pero no le pidamos a los pocos que hay FPGA que pierdan su valioso tiempo en esas cosas. Y no es solo retrasarles el desarrollo de cores (que es lo de menos), es que esos tios van a llegar a un punto que se van hartar y mas si les exigimos aun mas trabajo y de mantenimiento (que es ademas lo menos interesante). Y el dia que se harten a ver cuantos aparecen con el conocimiento necesario y las ganas para tomar el relevo...

Es que teneis montones de proyectos de emuladores y montones de sistemas mucho mas baratos, mas potentes, y con muchisimo mas soporte detras si los quereis. No veo esa necesidad de meter emuladores o media centers en un sistema mas caro, menos potente (a nivel de procesador, memoria, etc) y con infinitamente peor soporte... si alguien me lo explica pues bienvenido sea, porque yo no lo entiendo.

Vamos a ver... ¿Cómo va a ser una mala optimización de los recursos humanos hacer eso? En todo caso, sería un mal uso si tú fueras uno de los programadores, y el proyecto Mister te obligase a portar emuladores a Mister cuando tú lo que quieres es desarrollar más cores FPGA; pero no me parece que sea esa la situación. Me imagino que la documentación, que es lo importante, estará perfectamente preservada, y creo que tenemos la eternidad para ir mejorando sin prisas, con cada dev haciendo lo que quiera.

Si yo tuviera la Mister, y fuera tan buena, completa y perfecta como se dice, realmente no me preocuparía mucho por los experimentos o proyectos que quieran llevar a cabo los desarrolladores; a no ser que yo considerase que hubiera mucho que perfeccionar. Lo pintas como si tuvieras mucha prisa o necesidad, cuando insisto, se supone que se tiene Neo-Geo, CPS1 y muchos sistemas inferiores a pleno rendimiento.

Sobre lo de que no comparten lineas de código, y tener que determinar por ello que son cosas diferentes, honestamente no sé que pensar, porque creo que se puede dar el caso de que dos programas de software no compartan ni una sola linea de código, pero que hagan exactamente lo mismo y a los mismos tiempos. Igualmente, diría que se puede dar el mismo caso al programar chips.

En todo caso, se implemente como se implemente cada información en cada medio, quiero decir algo respecto a este punto, que me indicabas antes:

jimi escribió:Me parece bien que se usen implementaciones basadas en los descubrimientos de la comunidad en algunos chips de los que aun no se tiene documentacion oficial o decapado del chip ya que al final es como tener el hardware original con ese chip distinto en su implementacion pero que usa el mismo interface con el sistema y es compatible (o no al 100% aun). En el momento que se haga un decapado pues se sustituye por la implementacion real y listo, pero mientras no hay otra opcion mejor pues es una solucion valida.

Por un lado dices que portar emuladores de forma experimental o práctica al ARM supone mal-optimizar recursos humanos, mientras por otra parte das el visto bueno a portar cores a fpga a ciegas, por falta de pan (aka: datos precisos sobre cada chip).

Bajo mi punto de vista, si realmente quieres ser tan estricto y preciso con el proyecto, lo primero que tienes que esperar es que se desarrollen cores únicamente basados en información fiel, fruto de esquemas oficiales o de documentos sobres los chips a implementar, o bien extrayendo la información mediante la disección física de cada uno, y que tampoco se malgasten esos recursos humanos desarrollando cores fgpa con la carencia de esa información.

Lo que estás diciendo ahí es literalmente que te vale una implementación imprecisa a falta de la precisa, con tal que de que funcione por FPGA.

Sobre lo que dices en el último párrafo de ahora, no olvides que esto no lo hacen porque yo lo pida y/o lo necesite para pillarme una Mister; es más, ni se me había ocurrido, y a mí me valdría la Mister sin ello. Estas son cosas que salen únicamente desde dentro del proyecto, siendo idea de los desarrolladores, y dudo mucho que actúen en base a lo que yo quiera (además, ni lo he pedido).

¿Que me reconforta ver como los emuladores os invaden? Pues ciertamente sí, me hace gracia, por la fobia que le tienen algunos, más que nada, y porque confirma más o menos mi punto de vista. También me parece algo interesante para hacer pruebas, y comprobar posibles diferencias entre emulación y FPGA en la misma máquina. Pero de ahí a necesitar una Mister para hacer el trabajo de un Rpi a medias... ya te digo desde ya que no.

@gynion

La mayoría de los que reniegan de la emulación son gente que basa su experiencia de emulación en raspberry's Pi o Vetustos Pentiums 4 que tienen en un arcade con emuladores funcionando en DOS.

gynion escribió:

jimi escribió:Te estoy explicando que la implementacion en HDL como en las FPGAs y la implementacion en software de los emuladores no tienen absolutamente nada que ver, ni una sola linea de codigo se va a compartir o servir de uno al otro. Lo que se comparte y es lo interesante es toda la documentacion de como funcionan los sistemas.

Si se decapa un chip o se consigue documentacion de como esta hecho internamente (o se deduce como podria estar por como funciona externamente), esa informacion es la importante. No importa el como se programe en software un emulador para simular ese sistema.

Usar recursos en mantener unos emuladores por software en vez de aprovecharlos en mantener y desarrollar los cores FPGA es un atraso, y mas cuando desarrolladores software hay a patadas y desarrolladores FPGA hay muy muy pocos. Es una mala optimizacion de los recursos humanos de que se dispone se mire por donde se mire.
Como ya dije el que quiera emuladores que los meta, que desarrolladores por software capaces para ello seguro que hay a patadas, pero no le pidamos a los pocos que hay FPGA que pierdan su valioso tiempo en esas cosas. Y no es solo retrasarles el desarrollo de cores (que es lo de menos), es que esos tios van a llegar a un punto que se van hartar y mas si les exigimos aun mas trabajo y de mantenimiento (que es ademas lo menos interesante). Y el dia que se harten a ver cuantos aparecen con el conocimiento necesario y las ganas para tomar el relevo...

Es que teneis montones de proyectos de emuladores y montones de sistemas mucho mas baratos, mas potentes, y con muchisimo mas soporte detras si los quereis. No veo esa necesidad de meter emuladores o media centers en un sistema mas caro, menos potente (a nivel de procesador, memoria, etc) y con infinitamente peor soporte... si alguien me lo explica pues bienvenido sea, porque yo no lo entiendo.

Vamos a ver... ¿Cómo va a ser una mala optimización de los recursos humanos hacer eso? En todo caso, sería un mal uso si tú fueras uno de los programadores, y el proyecto Mister te obligase a portar emuladores a Mister cuando tú lo que quieres es desarrollar más cores FPGA; pero no me parece que sea esa la situación. Me imagino que la documentación, que es lo importante, estará perfectamente preservada, y creo que tenemos la eternidad para ir mejorando sin prisas, con cada dev haciendo lo que quiera.

Si yo tuviera la Mister, y fuera tan buena, completa y perfecta como se dice, realmente no me preocuparía mucho por los experimentos o proyectos que quieran llevar a cabo los desarrolladores; a no ser que yo considerase que hubiera mucho que perfeccionar. Lo pintas como si tuvieras mucha prisa o necesidad, cuando insisto, se supone que se tiene Neo-Geo, CPS1 y muchos sistemas inferiores a pleno rendimiento.

Sobre lo de que no comparten lineas de código, y tener que determinar por ello que son cosas diferentes, honestamente no sé que pensar, porque creo que se puede dar el caso de que dos programas de software no compartan ni una sola linea de código, pero que hagan exactamente lo mismo y a los mismos tiempos. Igualmente, diría que se puede dar el mismo caso al programar chips.

En todo caso, se implemente como se implemente cada información en cada medio, quiero decir algo respecto a este punto, que me indicabas antes:

jimi escribió:Me parece bien que se usen implementaciones basadas en los descubrimientos de la comunidad en algunos chips de los que aun no se tiene documentacion oficial o decapado del chip ya que al final es como tener el hardware original con ese chip distinto en su implementacion pero que usa el mismo interface con el sistema y es compatible (o no al 100% aun). En el momento que se haga un decapado pues se sustituye por la implementacion real y listo, pero mientras no hay otra opcion mejor pues es una solucion valida.

Por un lado dices que portar emuladores de forma experimental o práctica al ARM supone mal-optimizar recursos humanos, mientras por otra parte das el visto bueno a portar cores a fpga a ciegas, por falta de pan (aka: datos precisos sobre cada chip).

Bajo mi punto de vista, si realmente quieres ser tan estricto y preciso con el proyecto, lo primero que tienes que esperar es que se desarrollen cores únicamente basados en información fiel, fruto de esquemas oficiales o de documentos sobres los chips a implementar, o bien extrayendo la información mediante la disección física de cada uno, y que tampoco se malgasten esos recursos humanos desarrollando cores fgpa con la carencia de esa información.

Lo que estás diciendo ahí es literalmente que te vale una implementación imprecisa a falta de la precisa, con tal que de que funcione por FPGA.

Sobre lo que dices en el último párrafo de ahora, no olvides que esto no lo hacen porque yo lo pida y/o lo necesite para pillarme una Mister; es más, ni se me había ocurrido, y a mí me valdría la Mister sin ello. Estas son cosas que salen únicamente desde dentro del proyecto, siendo idea de los desarrolladores, y dudo mucho que actúen en base a lo que yo quiera (además, ni lo he pedido).

¿Que me reconforta ver como los emuladores os invaden? Pues ciertamente sí, me hace gracia, por la fobia que le tienen algunos, más que nada, y porque confirma más o menos mi punto de vista. También me parece algo interesante para hacer pruebas, y comprobar posibles diferencias entre emulación y FPGA en la misma máquina. Pero de ahí a necesitar una Mister para hacer el trabajo de un Rpi a medias... ya te digo desde ya que no.

Son cosas totalmente distintas, los emuladores que conocemos son una serie de instrucciones que se ejecutan sobre un procesador punto, se pueden usar lenguajes de programacion de bajo o alto nivel (tienes emuladores hechos en javascript incluso) o en ensamblador pero al final es codigo maquina que va a ejecutar un procesador de una plataforma concreata y que no tiene absolutamente nada que ver con el sistema o plataforma que intenta emular.
En una FPGA se diseña un hardware usando HDL (bien sea VHDL, bien sea Verilog HDL o bien sea SystemVerilog), HDL no es un lenguaje de programacion, es un lenguage de descripcion de hardware. No se le dice al procesador de turno que tiene que hacer, simplemente se describe el hardware en cuestion.

Es muchisimo mas complicado hacer un emulador de un sistema, lleva muchisimo mas tiempo y se necesitan monton de recursos y jamas se va a comportar exactamente como el sistema que quieres implementar. Al fin y al cabo con un emulador estas intentando que un sistema se comporte como otro sistema totalmente diferente, es algo sumamente complicado y que lleva muchisimo tiempo y trabajo.
De hecho solo tienes que mirar cualquier emulador de sistemas de 8 y 16 bits y como despues de llevar 20 años de desarrollo con montones de devs aun a dia de hoy son bastante mediocres comparados al sistema real y requieren procesadores cientos de veces mas potentes que el sistema que quieren emular. Mientras en cuestion de meses estan sacando sistemas en la FPGA implementados usando HDL que se comportan como el sistema original y encima hechos por 1 sola persona.

Y no se explicame donde los desarrolladores de FPGA han dicho que quieren meter emuladores en la MiSTer... los que lo estan pidiendo solo son algunos pocos usuarios, de hecho estan pidiendo que se lo hagan a los devs de la MiSTer (que manda narices vamos), que lo hagan ellos si quieren. De hecho recuerdo en el antiguo foro de mister como algunos postearon pidiendolo y sorgelig posteo que no iba a perder el tiempo en eso. Asi que no se de donde sacas que ellos son los que quieren dedicarse a meter los emuladores (que si quisieran estan en su derecho de hacerlo por supuesto).
Yo creo que la gente que llora para que le pongan emuladores en la mister lo hace por desconocimiento. Nadie les impide meterlos si quieren...

Si no conoces el interior de un chip de un sistema (compuesto por infinidad de chips), puedes intentar hacer ingenieria inversa (que es lo que se hizo toda la vida) y ver como se comporta externamente, de hecho puedes llegar a hacer una implementacion de ese chip en FPGA totalmente compatible con el original y por dentro estar implementando de otra manera distinta. Cuales son las pegas de hacer eso, pues que pueden facilmente aparecer bugs que no habia en el original o que algunos que habia en el original no aparezcan en el nuevo.
Que si tuvieramos las especificaciones concretas del chip aun sin saber su implementacion concreta se podria hacer un chip 100% compatible con el original, que podrias reemplazarlo por los originales en una consola real y no se notaria la diferencia. De hecho muchos sistemas originales tienen revisiones de chips implementados de diferente manera pero que hacen el mismo trabajo .

Yo no se que problema le ves a que se creen chips compatibles aunque no sean al 100% mientras no se consiga la documentacion del chip oficial (dificil) o se decape el chip (mas plausible pero lleva tiempo y dinero). Por algun sitio se empieza. Lo curioso es que aun sin tener documentacion perfecta de todo el sistema se va a implementar en FPGA muchisimo mas rapido y va a funcionar de manera estable, sin que haya el minimo retraso porque un proceso del sistema necesita del procesador en ese momento o porque hay que tener acceso a 3 buses de datos al mismo tiempo o hay que hacerlo coincidir con el timing del back porch, front porch, etc .

Es que los que piden los emuladores en la MiSTer son curiosamente los que jamas han probado una FPGA... no entiendo vuestra fijacion con que metan algo en un sistema que ni teneis ni os planteais tener porque estais muy contentos con los emuladores en los miles de sistemas disponibles. No le veo ningun sentido.

@DJ Deu Nadie reniega de la emulacion, la emulacion es algo perfectamente valido y seguira existiendo toda la vida. Lo que tiene poco sentido es meter emuladores en una FPGA y mucho menos pedir a los devs de las FPGA que sean los que pierdan su tiempo en ello.
Es que parece que tienes que estar en contra de la emulacion si prefieres implementaciones en FPGA. De hecho seguramente en sistemas modernos se tarde muchisimo en poder implementarlos en una FPGA o llegue a merecer la pena algun dia hacerlo. Los sistemas antiguos eran arquitecturas muy diferentes entre si, por eso las FPGA son la mejor opcion de largo, mientras que los sistemas modernos son todos de una arquitectura muy similar y simplificada donde la emulacion se vuelve mas sencilla y lo que interesa es la potencia de CPU y GPU.

No se porque teneis que ser tan radicales. Que no vea con buenos ojos dar soporte oficial a emuladores o media centers en la MiSTer no quiere decir que odie los emuladores y los media centers... creo que no es tan dificil de entender .

DJ Deu escribió:@gynion

La mayoría de los que reniegan de la emulación son gente que basa su experiencia de emulación en raspberry's Pi o Vetustos Pentiums 4 que tienen en un arcade con emuladores funcionando en DOS.

Luego al final juegan cuatro gatos; el resto sólo compara.

jimi escribió:Son cosas totalmente distintas, los emuladores que conocemos son una serie de instrucciones que se ejecutan sobre un procesador punto, se pueden usar lenguajes de programacion de bajo o alto nivel (tienes emuladores hechos en javascript incluso) o en ensamblador pero al final es codigo maquina que va a ejecutar un procesador de una plataforma concreata y que no tiene absolutamente nada que ver con el sistema o plataforma que intenta emular.
En una FPGA se diseña un hardware usando HDL (bien sea VHDL, bien sea Verilog HDL o bien sea SystemVerilog), HDL no es un lenguaje de programacion, es un lenguage de descripcion de hardware. No se le dice al procesador de turno que tiene que hacer, simplemente se describe el hardware en cuestion.

Es muchisimo mas complicado hacer un emulador de un sistema, lleva muchisimo mas tiempo y se necesitan monton de recursos y jamas se va a comportar exactamente como el sistema que quieres implementar. Al fin y al cabo con un emulador estas intentando que un sistema se comporte como otro sistema totalmente diferente, es algo sumamente complicado y que lleva muchisimo tiempo y trabajo.
De hecho solo tienes que mirar cualquier emulador de sistemas de 8 y 16 bits y como despues de llevar 20 años de desarrollo con montones de devs aun a dia de hoy son bastante mediocres comparados al sistema real y requieren procesadores cientos de veces mas potentes que el sistema que quieren emular. Mientras en cuestion de meses estan sacando sistemas en la FPGA implementados usando HDL que se comportan como el sistema original y encima hechos por 1 sola persona.

Bueno, esa forma de verlo contradice lo que pasa en la practica; o sea, en teoría un emulador conlleva mucho más tiempo de desarrollo y complicación que un core fpga... pero resulta que el primer emulador de Neo-Geo surgió con el sistema MVS-AES todavía vivo, sobre 1998, mientras que a la tecnología FPGA le ha costado nada menos que unos 30 años implementar Neo-Geo, celebrándolo como si se hubiese inventado la rueda, cuando como mucho solo supone una depuración más a la ahora de jugar, que unos valoraran mucho, y otros ni notarán; por lo que no será poca cosa lo logrado, pero tampoco una revolución en general, ni mucho menos barato (en ningún sentido).

Estás contando la fase final de la implementación FPGA como si fuera el total, y no. ¿O te crees que el camino para ver a Dreamcast en FPGA va a ser facilito, barato y rápido? Porque los sistemas que ahora abarca Mister están ya trilladísimos en emulación, pero para asegurar lo que dices la tecnología FPGA tendría que ser capaz de ir a la par o por delante de la emulación en cuanto a los sistemas que implemente, y para nada así, ni se espera que sea así, sino totalmente a la inversa.

jimi escribió:Y no se explicame donde los desarrolladores de FPGA han dicho que quieren meter emuladores en la MiSTer... los que lo estan pidiendo solo son algunos pocos usuarios, de hecho estan pidiendo que se lo hagan a los devs de la MiSTer (que manda narices vamos), que lo hagan ellos si quieren. De hecho recuerdo en el antiguo foro de mister como algunos postearon pidiendolo y sorgelig posteo que no iba a perder el tiempo en eso. Asi que no se de donde sacas que ellos son los que quieren dedicarse a meter los emuladores (que si quisieran estan en su derecho de hacerlo por supuesto).
Yo creo que la gente que llora para que le pongan emuladores en la mister lo hace por desconocimiento. Nadie les impide meterlos si quieren...

Solo he opinado que no me parece mal, si los devs lo estiman interesante. Al final está en manos de los desarrolladores hacer caso o no.

jimi escribió:Si no conoces el interior de un chip de un sistema (compuesto por infinidad de chips), puedes intentar hacer ingenieria inversa (que es lo que se hizo toda la vida) y ver como se comporta externamente, de hecho puedes llegar a hacer una implementacion de ese chip en FPGA totalmente compatible con el original y por dentro estar implementando de otra manera distinta. Cuales son las pegas de hacer eso, pues que pueden facilmente aparecer bugs que no habia en el original o que algunos que habia en el original no aparezcan en el nuevo.
Que si tuvieramos las especificaciones concretas del chip aun sin saber su implementacion concreta se podria hacer un chip 100% compatible con el original, que podrias reemplazarlo por los originales en una consola real y no se notaria la diferencia. De hecho muchos sistemas originales tienen revisiones de chips implementados de diferente manera pero que hacen el mismo trabajo .

Bueno, si tú aceptas esa idea como alternativa al no poder conocer al dedillo el chip que se quiera replicar, no te lo voy a discutir. La frase final que escries en este párrafo ya es como para relativizar y poner en cuestión muchas cosas, pero está claro que eso es solo bajo mi punto de vista, no del tuyo.

jimi escribió:Yo no se que problema le ves a que se creen chips compatibles aunque no sean al 100% mientras no se consiga la documentacion del chip oficial (dificil) o se decape el chip (mas plausible pero lleva tiempo y dinero). Por algun sitio se empieza. Lo curioso es que aun sin tener documentacion perfecta de todo el sistema se va a implementar en FPGA muchisimo mas rapido y va a funcionar de manera estable, sin que haya el minimo retraso porque un proceso del sistema necesita del procesador en ese momento o porque hay que tener acceso a 3 buses de datos al mismo tiempo o hay que hacerlo coincidir con el timing del back porch, front porch, etc .

Es que los que piden los emuladores en la MiSTer son curiosamente los que jamas han probado una FPGA... no entiendo vuestra fijacion con que metan algo en un sistema que ni teneis ni os planteais tener porque estais muy contentos con los emuladores en los miles de sistemas disponibles. No le veo ningun sentido.

En todo caso, el problema debería vérselo aquel que busque precisión al 100%, aquel que diga que no le vale la emulación por supuestamente imprecisa, pues en ese caso tampoco le valdrá un core sacado con tecnologia inversa, porque después todo son parches que corrigen bugs y más bugs, en un ensayo y error continuo, bastante alejado de esa precisión instantánea de la que se presume. En cambio, por mi parte ya te he comentando que soy bastante flexible en esto.

Sobre lo que dices al final del quote, para nada deberías incluirme entre ellos. Ya te digo que no he pedido en ningún momento que le metan emuladores a Mister, y solo he dicho que no me parece mal.

Le han regalado a jotego la placa del outrun,

Madre mía como se pueda portar

https://twitter.com/topapate/status/126 ... 48007?s=19

@jimi

Lo de la emulación no lo decía por ti, lo decía referido a que usualmente quienes más se quejan de ella, suelen ser los que emulan en entornos poco optimos.

Emulando en las condiciones que expongo antes, comparado con una MiSTer es obvio que les parezca lo mejor, pero no es una opinión muy válida.

@gynion Yo tampoco he dicho que me parezca mal que metan emuladores, solo he dicho que no los metan oficialmente (vamos que los pocos devs que oficialmente estan desarrollando cores pierdan el tiempo el algo que no aporta en mi opinion nada). El que los quiera que los meta y si quiere un mediacenter pues lo mismo, por mi perfecto.

Y los devs oficiales tengo mis dudas de que pierdan el tiempo en ello, al menos sorgelig (que es el que mantiene el proyecto) ya dijo que no iba a perder el tiempo en eso respondiendole a un usuario en el antiguo foro.

No se de donde sacas que ha llevado 30 años implementar neogeo en FPGA... una cosa es que la neogeo saliese hace 30 años y hace poco que han realizado una implementacion en FPGA, pero implementarla en FPGA a furrkek le llevo pocos meses y la primera version que saco ya corria todos los juegos de puta madre .

Ya te digo que lo que mas lleva tiempo es la investigacion, el decapado de chips y la ingenieria inversa. Pero luego la implementacion en FPGA es algo sencillo, lleva mas tiempo escribir la descripcion en si, pero es escribir la descripcion de lo que hace, no hay que programar nada ni hacer pruebas continuamente como los emuladores....

Hacer que una plataforma totalmente diferente intente ejecutar un programa que emulara otra plataforma que es muy distinta es algo muy muy complicado de hacer, requiere años aunque tengas toda la documentacion a mano... no es algo para nada sencillo y vas a tener revisiones y revisiones hasta que se comporte igual (que ya es muy complicado), y menos que se comporte igual en todos los casos .

Lo de los emuladores es algo tambien muy interesante, estas ejecutando software de una plataforma en otra completamente distinta y seguiran existiendo toda la vida. Pero es algo totalmente distinto a implementar esa plataforma tal cual. Que puede que no dispongas de documentacion completa de esa plataforma y habra chips que desconozcas como estan hechos, por supuesto y en ese caso ese chip seguramente no se comporte como el sistema original tanto en emulacion como en su implementacion FPGA (como si decides hacer un ASIC si te sobra el dinero xD)... creo que no hay que ser muy listo para darse cuenta de cosas tan obvias.

Que ejemplos de cores que no estan bien implementados habia 2 muy claros que eran el de PC Engine y el del 486. Aunque este ultimo mes de paso que se le implemento al core de PC Engine el soporte de CD se arreglo el core y ahora va de puta madre (dudo que haya un emulador que lo emule siquiera parecido y sino enlazamelo).

Al final yo creo que todos estamos de acuerdo entonces, que no pierdan el tiempo los devs en meter emuladores en la MiSTer y que el que los quiera que se lo meta de manera extraoficial y listo .

DJ Deu escribió:@jimi

Lo de la emulación no lo decía por ti, lo decía referido a que usualmente quienes más se quejan de ella, suelen ser los que emulan en entornos poco optimos.

Emulando en las condiciones que expongo antes, comparado con una MiSTer es obvio que les parezca lo mejor, pero no es una opinión muy válida.

Depende lo que quieras, pero es muy dificil que un emulador en otro sistema se comporte igualmente que el sistema que intentas emular, es muchisimo trabajo de desarrollo hacerlo y ademas necesitas un hardware muy muy superior para que simplemente no tengan que hacer frameskips porque no le dio tiempo a ejecutar todo lo necesario en ese frame en cuestion. Y se hacen monton de optimizaciones para que el sistema requiera menos recursos que hacen en muchos casos que se comporte de manera muy distinta y pueda llevar a bugs, esta claro que hay excepciones donde se busca mas la fidelidad al rendimiento (pero son las excepciones no la regla tristemente, de hecho en alguno sacan versiones diferentes del mismo emulador segun prefieras mas fidelidad o mas rendimiento).

jimi escribió:
No se de donde sacas que ha llevado 30 años implementar neogeo en FPGA... una cosa es que la neogeo saliese hace 30 años y hace poco que han realizado una implementacion en FPGA, pero implementarla en FPGA a furrkek le llevo pocos meses y la primera version que saco ya corria todos los juegos de puta madre .

A Furrtek le llevo poco tiempo hacer la implementación porque lleva años decapando los chips de la NeoGeo y creando versiones libres en VHDL para poder reparar placas dañadas.

Cuando se quiso dar cuenta tenía una NeoGeo en código, pero eso fue lo que tardo unos meses (gracias a la ayuda de otros desarrolladores que le guiaron en el proceso de creación del core).

El resto de implementaciones "rápidas" vienen de trasladar la implementación de Mame y es ahora cuando se está poniendo de moda el decapar y convertir, pero por desgracia casi todo lo que tenemos son implementaciones hardware muy muy cercanas a la placa real pero que todavía no se comportan como la placa real, al no tener implementados total o correctamente todos los componentes.

Sobre el argumento de que el desarrollador que mete el emulador no se centra en el core FPGA, os diré que el que mete el emulador no iba a hacer el core, y el que hace el core no deja de hacerlo porque haya un emulador. Pero el argumento de "para eso poned al lado una raspberry" lo podemos aplicar a todo, y así acabamos de un plumazo con la scene del mundo de las consolas. Y a tomar por culo, ¿no?

Hodor escribió:Verás, las FPGAs tienen una capacidad máxima que limita la cantidad y complejidad de la electrónica que pretende simular/replicar. Es decir, en el caso concreto de la Mister una consola relativamente compleja como la PSP original muy probablemente no quepa. Algo bastante complejo como la Sega Dreamcast o la Playstation 2 definitivamente no entra.

Y luego conviene tener en cuenta que, aparte de lo anterior, alguien debe de programar y desarrollar esa adaptación. Puede ocurrir que por su complejidad nadie quiera/sepa abordarla, o por simple falta de interés.

Un saludo.

Muchas gracias por la info compañero, es muy interesante todo lo que comentas.
Así pues, para consolas complejas, a fecha de 2020, solo es posible hacer emulación.
Por consolas complejas entendemos a partir de Dreamcast, PS2 y PSP. Todo lo que sea posterior no se puede simular y todo lo que sea anterior sí se puede simular con mister (N64, NeoGeoCD, MegaCD/32X...)

Aún así no descarto comprar la MISTER, el hecho que pueda jugar con las consolas antiguas exactamente igual que las originales es algo me gustaría mucho. Aunque creo que previamente probaré a fondo los mejores emuladores para cada sistema para conocer el grado de calidad que tienen. Hace años que no pruebo emuladores y no sé como han evolucionado hasta nuestros días.

Sobre el tema de emulación, lo que diferencia a MISTER, ¿sería principalmente la velocidad y lag con el que se ejecuta el juego? recuerdo que cuando usé algunos emuladores antiguos de SNES desde el PC, la velocidad del juego a veces se aceleraba o se ralentizaba.

entre mister/emuladores ¿hay diferencias también en la construcción de los polígonos de imagen del juego? es decir, un emulador moderno y MISTER ¿muestran la misma imagen del juego? ¿o con mister está como en el original y con el emulador los polígonos son "aproximados" a las formas originales? he oído que en algunos juegos emulados las formas de las imágenes son diferentes a las originales.

En lo de la calidad de imagen en pantalla/altavoces (fidelidad de color y audio), supongo que ahí es donde MISTER claramente arrasa a cualquier emulador.

Gracias y un saludo!

Shikamaru escribió:

jimi escribió:
No se de donde sacas que ha llevado 30 años implementar neogeo en FPGA... una cosa es que la neogeo saliese hace 30 años y hace poco que han realizado una implementacion en FPGA, pero implementarla en FPGA a furrkek le llevo pocos meses y la primera version que saco ya corria todos los juegos de puta madre .

A Furrtek le llevo poco tiempo hacer la implementación porque lleva años decapando los chips de la NeoGeo y creando versiones libres en VHDL para poder reparar placas dañadas.

Cuando se quiso dar cuenta tenía una NeoGeo en código, pero eso fue lo que tardo unos meses (gracias a la ayuda de otros desarrolladores que le guiaron en el proceso de creación del core).

El resto de implementaciones "rápidas" vienen de trasladar la implementación de Mame y es ahora cuando se está poniendo de moda el decapar y convertir, pero por desgracia casi todo lo que tenemos son implementaciones hardware muy muy cercanas a la placa real pero que todavía no se comportan como la placa real, al no tener implementados total o correctamente todos los componentes.

Sobre el argumento de que el desarrollador que mete el emulador no se centra en el core FPGA, os diré que el que mete el emulador no iba a hacer el core, y el que hace el core no deja de hacerlo porque haya un emulador. Pero el argumento de "para eso poned al lado una raspberry" lo podemos aplicar a todo, y así acabamos de un plumazo con la scene del mundo de las consolas. Y a tomar por culo, ¿no?

No trasladaron la implemantacion de mame a FPGA porque son 2 cosas totalmente distintas y que no tienen absolutamente nada que ver. Lo unico que utilizaron son los conocimientos y documentacion que se fue recopilando durante este tiempo y que se utilizaria en mame y seguramente en mas emuladores, como tambien para hacer wikis...

Obviamente que furrtek tardo mas tiempo en decapar los chips y analizar los circuitos internos para saber como funcionan y documentarlos, eso es lo que mas tiempo lleva con diferencia. Pero desde que tienes la documentacion del sistema, implementarlo en FPGA es cuestion de pocos meses (y eso contando lo que lleva adaptarlo al framework especifico de MiSTer con el que no tendria ninguna experiencia previa).
Pero ahora buscame a alguien que te hace un emulador de neogeo de 0 disponiendo de esa documentacion y que funcione decentemente en cuestion de meses...
Y eso que por cada persona que tenga experiencia en HDL vas a encontrar seguramente a miles de personas con experiencia en desarrollo software .

Por eso el precio y capacidades de las actuales FPGA nos dan una posibilidad que no disponiamos años atras para implementaciones de sistemas desarrolladas infinitamente mas rapido y que se van a comportar como el sistema original siempre que se disponga de la documentacion necesaria. En cambio hacerlo con emuladores es muchisimo mas complejo y es muy muy dificil que se comporte exactamente como el sistema original y aun mas dificil el que en todo momento se comporte como el sistema original.
Y ademas el sistema FPGA en todo momento se va a comportar como debe, jamas vas a tener un frameskip (si es que el sistema original no lo tenia obviamente, si el original los tenia los vas a tener y exactamente los mismos y en los mismos sitios ).
Y encima consumiendo muy poca energia electrica y siendo compatibles con multitud de perifericos a diferencia del sistema original .

@cr0nos8797 Visualmente si el emulador lleva suficientes años de desarrollo y con gente medianamente competente deberia verse exactamente igual (eso no libra que pueda aparecer algun bug visual puntual en algun juego, o que no apareza a diferencia del sistema original). Donde mas se nota es en los timings ya que es lo mas complicado de emular por software y sobretodo en el sonido.

jimi escribió:

Shikamaru escribió:

jimi escribió:
No se de donde sacas que ha llevado 30 años implementar neogeo en FPGA... una cosa es que la neogeo saliese hace 30 años y hace poco que han realizado una implementacion en FPGA, pero implementarla en FPGA a furrkek le llevo pocos meses y la primera version que saco ya corria todos los juegos de puta madre .

A Furrtek le llevo poco tiempo hacer la implementación porque lleva años decapando los chips de la NeoGeo y creando versiones libres en VHDL para poder reparar placas dañadas.

Cuando se quiso dar cuenta tenía una NeoGeo en código, pero eso fue lo que tardo unos meses (gracias a la ayuda de otros desarrolladores que le guiaron en el proceso de creación del core).

El resto de implementaciones "rápidas" vienen de trasladar la implementación de Mame y es ahora cuando se está poniendo de moda el decapar y convertir, pero por desgracia casi todo lo que tenemos son implementaciones hardware muy muy cercanas a la placa real pero que todavía no se comportan como la placa real, al no tener implementados total o correctamente todos los componentes.

Sobre el argumento de que el desarrollador que mete el emulador no se centra en el core FPGA, os diré que el que mete el emulador no iba a hacer el core, y el que hace el core no deja de hacerlo porque haya un emulador. Pero el argumento de "para eso poned al lado una raspberry" lo podemos aplicar a todo, y así acabamos de un plumazo con la scene del mundo de las consolas. Y a tomar por culo, ¿no?

No trasladaron la implemantacion de mame a FPGA porque son 2 cosas totalmente distintas y que no tienen absolutamente nada que ver. Lo unico que utilizaron son los conocimientos y documentacion que se fue recopilando durante este tiempo y que se utilizaria en mame y seguramente en mas emuladores, como tambien para hacer wikis...

Obviamente que furrtek tardo mas tiempo en decapar los chips y analizar los circuitos internos para saber como funcionan y documentarlos, eso es lo que mas tiempo lleva con diferencia. Pero desde que tienes la documentacion del sistema, implementarlo en FPGA es cuestion de pocos meses (y eso contando lo que lleva adaptarlo al framework especifico de MiSTer con el que no tendria ninguna experiencia previa).
Pero ahora buscame a alguien que te hace un emulador de neogeo de 0 disponiendo de esa documentacion y que funcione decentemente en cuestion de meses...
Y eso que por cada persona que tenga experiencia en HDL vas a encontrar seguramente a miles de personas con experiencia en desarrollo software .

Por eso el precio y capacidades de las actuales FPGA nos dan una posibilidad que no disponiamos años atras para implementaciones de sistemas desarrolladas infinitamente mas rapido y que se van a comportar como el sistema original siempre que se disponga de la documentacion necesaria. En cambio hacerlo con emuladores es muchisimo mas complejo y es muy muy dificil que se comporte exactamente como el sistema original y aun mas dificil el que en todo momento se comporte como el sistema original.
Y ademas el sistema FPGA en todo momento se va a comportar como debe, jamas vas a tener un frameskip (si es que el sistema original no lo tenia obviamente, si el original los tenia los vas a tener y exactamente los mismos y en los mismos sitios ).
Y encima consumiendo muy poca energia electrica y siendo compatibles con multitud de perifericos a diferencia del sistema original .

@cr0nos8797 Visualmente si el emulador lleva suficientes años de desarrollo y con gente medianamente competente deberia verse exactamente igual (eso no libra que pueda aparecer algun bug visual puntual en algun juego, o que no apareza a diferencia del sistema original). Donde mas se nota es en los timings ya que es lo mas complicado de emular por software y sobretodo en el sonido.

A ver, por estar implementado en una FPGA no significa que sea 100% fiel.

Jotego no hace más que sacar reports en los que explica en detalle que sigue teniendo que interpretar la lógica de algunos circuitos con un analizador lógico, sin saber muy bien aún que están haciendo en realidad.

A medida que va cogiendo mediciones de las placas va modificando los timmings de la electrónica simulada para que sea todavía más fiel, pero no por tenerlo implementado es automáticamente fiel.

El core de Atari ST que teníamos hasta hace un mes era lo puñetero peor y el X68000 no servía ni para ver la bios del PC. Ambos sistemas han recibido un subidón reciente que los ha dejado bastante pulidos, pero en ambos casos había documentación de los chips e implementaciones en otras placas, y se ha tardado más de un año en que aparezcan dichos ports (diría años, pero me cargo la fecha original de salida del core de Atari en Mist por ejemplo).

Muchos autores, como el del core de Rygar, tiran de emulación dentro de su implementación, al meter por ejemplo un emulador del Yamaha OPL3 mediante la implementación de un Z80.

Aquí tienes el artículo de Jotego:

https://www.patreon.com/posts/emulators-inside-37036334

Hablando tanto con él como con Shane, contaban que (y explico lo del mame) lo toman muchas veces como referencia, llegando a dejar implementado el chip en las primeras versiones con los resultados de la implementación de mame. El objetivo real de Mame es preservar las máquinas, por lo que su meta es la precisión y algunos de los chips históricos están recreados a la perfección y de ahí de entre otras fuentes viene el código que implementan en estos z80 (el caso del Rygar) para hacer el apaño.

Yo tengo mi Mister ya desde hace tiempo y soy patreon de varios autores, por lo que no me tienes que vender las bondades de las FPGA, pero es importante que seamos claros: que esté implementado no significa que la versión actual sea fiel.

Y sobre el tiempo de implementación, el propio Jotego te lo cuenta. No es tanto el tener los chips como el saber como cojones se hablan entre ellos y que importancia tiene la parte de lógica que no es implementable. Por lo que incluso con el decapado, una plataforma se puede llevar años en terminar.

@Shikamaru Y donde he dicho que tenga que ser 100% fiel por ser implementado en FPGA? (si puedes citamelo, no me gustan que pongan cosas en mi boca que no he dicho). He dicho claramente que teniendo la documentacion y sabiendo como funcionan los sistemas la implementacion FPGA se hace muchisimo mas rapido y facil y ademas sera 100% fiel en ese caso. Mientras que aun teniendo la documentacion y sabiendo perfectamente como funciona todo, hacer un emulador es una tarea infinitamente mas compleja, lleva muchisimo mas tiempo y es muy complicado que sea mas o menos fiel.

Que la herramienta sea buena no hace el trabajo perfecto si no se conoce como hay que hacerlo o el que lo hace no es muy bueno...

El proceso mas complejo y que se puede compartir es el de analisis, investigacion y documentacion de los sistemas a recrear/emular. Pero si luego de realizar ese trabajo tenemos la opcion de implementarlo mas rapidamente y de manera fiable, pues es una tonteria no aprovecharse de ello vamos.

Y ya no es el tema de hacerlo mas o menos fiable al sistema original, son muchas mas cosas ya que un emulador al final esta corriendo bajo un sistema operativo "normal" no es un sistema operativo en tiempo real encima, es un sistema operativo en el que la ejecucion de un programa no es previsible, tiene su tiempo de proceso y esta compartido con muchos otros procesos del sistema. Si se da el caso de que en un momento dado se necesitan recursos para atender otro proceso pues se puede dar el caso de no se ejecute a tiempo la frame actual o la reproduccion de sonido y haya un frameskip o un microcorte en el sonido. De hecho por eso se usan monton de buffers y chanchullos para evitar esos casos en lo maximo posible (que obviamente los buffers luego crear retrasos... hay un monton de complicaciones en los emuladores (como es normal ya que estamos ejecutando algo en otro sistema completamente distinto al original). Mientras qeu una FPGA jamas va a tener ningun problema de ejecucion no previsible, ya que al final recrea el hardware original tal cual, no hay que hacer apaños o va a variar entre ejecuciones... en una FPGA si necesitas 20 buses de datos con sus chips comunicandose a la vez... es algo simple y sencillo y que va a funcionar siempre bien. Hacer un emulador donde tengas que emular la comunicacion de varios buses y comunicaciones de chips simultaneamente requiere hacer un monton de optimizaciones e implementaciones muy disintas del sistema real ya en la mayoria de los casos en el sistema host tienes un solo procesador y 1 solo bus de comunicacion principal y encima eso compartido con un sistema operativo host y multiples procesos que no tienen nada que ver con el emulador...

jimi escribió:@Shikamaru Y donde he dicho que tenga que ser 100% fiel por ser implementado en FPGA? (si puedes citamelo, no me gustan que pongan cosas en mi boca que no he dicho). He dicho claramente que teniendo la documentacion y sabiendo como funcionan los sistemas la implementacion FPGA se hace muchisimo mas rapido y facil y ademas sera 100% fiel en ese caso. Mientras que aun teniendo la documentacion y sabiendo perfectamente como funciona todo, hacer un emulador es una tarea infinitamente mas compleja, lleva muchisimo mas tiempo y es muy complicado que sea mas o menos fiel.

Decir que una implementación en FPGA no tiene por qué ser 100% al original no es poner palabras en tu boca que no has dicho, sino puntualizar las que sí has dicho.

O sea, las FPGA pueden ser 100%, pueden técnica o teóricamente hablando, pero no quiere decir que los desarrolladores lo consigan. Y si resulta da igual que las FPGA no sean 100% fieles hasta que se depuren los cores, porque hay usuarios que no lo van a notar, igualmente se puede pensar lo mismo de los emuladores que le metiesen a Mister, que da lo mismo que no sean 100% fieles, porque hay gente que no lo notará debido a la insignificancia de las diferencias.

Yo creo que tbn hay que separar fidelidad, con calidad imagen y sonora.

Para que en ordenador un emulador llegue a los niveles de lag, filtros sonoros, sincronismo etc de una fpga,necesitas un maquina muy potente (runahead, y demas...)
Y señores emular retro con un i7 o i9 es matar moscas a cañonazos, todo para llegar a los niveles de precisión de una fpga que te puede costar 90 euros como la sidi.

ziu escribió:Y señores emular retro con un i7 o i9 es matar moscas a cañonazos, todo para llegar a los niveles de precisión de una fpga que te puede costar 90 euros como la sidi.

Igual te compras el i7 para emular Dreamcast, Saturn, PS2, PS3... y de paso lo aprovechas para emuladores cycle accurate de sistemas inferiores.

Porque visto así, también comprarse Mister para acabar rulando juegos de una Atari 2600 sería matar moscas a cañonazos.

@gynion Pero el consumo de un I7 o I9 es muchísimo mayor que el de la MiSTer, tenemos que comprobar todas las variables y ver si nos compensa o no.

Saludos.

AlterNathan escribió:@gynion Pero el consumo de un I7 o I9 es muchísimo mayor que el de la MiSTer, tenemos que comprobar todas las variables y ver si nos compensa o no.

Saludos.

Es que no hay opción en la lado FPGA si quieres Dreamcast, por ejemplo. Incluso una Rpi4 te puede valer, o muchos sistemas inferiores a un i7, de menor consumo.

Se está dando por hecho que aquel que se compra un i7 para emular lo hace porque solo quiere emular los sistemas disponibles en Mister, cuando en la mayoría de casos quiere mucho más.

@gynion Pero estamos en las mismas, yo tengo un I5 y no lo utilizo para emular una Master System, no tiene sentido por el consumo que gasto y con el FPGA pues es un consumo más comedido.

Y con la DreamCast pues casi igual, porque con una Jet Nano o la Shield TV (que gastan muy poco), lo prefiero al PC, creo que un PC de gama alta sería mejor para la WiiU, GC, PS2 y Switch para los demás sistemas creo que es mejor mirar si te compensa el gasto de comprar algún aparatejo o el consumo del PC.

Saludos.

@AlterNathan

Pues lo que he dicho, ¿no?

Aquí, en negrita:

gynion escribió:Es que no hay opción en la lado FPGA si quieres Dreamcast, por ejemplo. Incluso una Rpi4 te puede valer, o muchos sistemas inferiores a un i7, de menor consumo.

De todas formas, no veo problema en usar el mismo PC para emular Wii-U y SNES; es la misma perdida de tiempo jugando y gastando ingentes cantidades de energía.

Sería más rápido y sencillo decir "No juegues a juegos de Wii-U emulados, porque consumes mucha energía. Juega a Neo-Geo en Mister".

@gynion Es que yo he metido los PCs en el mismo saco, a veces me pasa porque no tengo mucha compresión lectora xD, me saqué primaria hace poco y antes era muy bestia escribiendo. Disculpas.

Saludos.

@AlterNathan

No hay de qué disculparse; a mí no me importa aclarar y charlar lo que haga falta, mientras haya buen rollo y buen humor. Además, que no te creas que yo soy muy estudioso.

ziu escribió:Yo creo que tbn hay que separar fidelidad, con calidad imagen y sonora.

Para que en ordenador un emulador llegue a los niveles de lag, filtros sonoros, sincronismo etc de una fpga,necesitas un maquina muy potente (runahead, y demas...)
Y señores emular retro con un i7 o i9 es matar moscas a cañonazos, todo para llegar a los niveles de precisión de una fpga que te puede costar 90 euros como la sidi.

Ninguno de los sistemas que implementa Mister necesita de un procesador de gama alta para emularlo al 100% de velocidad utilizando filtros o runahead.

Un saludo.

A mi sinceramente se me han quitado las ganas de jugar a cualquier emulador de 32bits para arriba,

Mucha gente que se ha pasado a fpga y que habla del sentir coinciden q con emuladores no sienten nada,como sin Alma, no creo que sea efecto placebo, es una realidad,

Jotego lo comparó con hablar con una persona real o con un loro que pronuncia mejor incluso que la persona, con fpga te está llegando las impresiones del hardware real ya que internamente funciona de forma parecida, con emulador es imitación, como el ejemplo del loro que repite sin saber que significa lo que dice...

ziu escribió:A mi sinceramente se me han quitado las ganas de jugar a cualquier emulador de 32bits para arriba,

Mucha gente que se ha pasado a fpga y que habla del sentir coinciden q con emuladores no sienten nada,como sin Alma, no creo que sea efecto placebo, es una realidad,

Jotego lo comparó con hablar con una persona real o con un loro que pronuncia mejor incluso que la persona, con fpga te está llegando las impresiones del hardware real ya que internamente funciona de forma parecida, con emulador es imitación, como el ejemplo del loro que repite sin saber que significa lo que dice...

Si quieren vender Mister... que te van a decir; pues marketing.

A mí me la pueden vender por Neo-Geo, porque tengo dos mandos de casualidad, la consola está imposible (y además tampoco me iba a comprar juegos, ni siquiera flashcarts a esos precios); pero de que empiezan con esos rollos anti-emuladores, ya me echan para atrás. Como si no fuera compatible hacer uso de ambas cosas, y como si las sensaciones tan particulares de unos tuvieran que ser de caracter universal.