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

jimi escribió:

Yaripon escribió:Yo no termino de enterarme muy bien como van algunas cosas de este cacharro. Me genera una curiosidad tremenda, eso sí. Alguien podría resolverme algunas dudillas??
1. Los puertos usb falsos raros que con un adaptador conectas los mandos originales, se supone que no meten lag, no?
2. Hay algún montaje que permita sacar imagen hdmi en proporción correcta, 1080p scanlines y sin meter latencia extra?
3. Saturn y Ps1 van bien y sin errores?
4. En caso de ser correcta la opción 2, así a ojimetro sobre cuanto saldría un pack básico que pudiera mover al menos la Nes y que después a futuro se pudiera ampliar para que le funcione todo lo demás? (Porque tengo entendido que para las otras hay que meter expansiones de ram y no se si algo más).

1.- Ese es el puerto SNAC y en mi opinion el utilizar un conector USB 3.0 no fue la mejor decision y genera mucha confusion, pero es entendible el porque lo hicieron (reduccion de costes porque un conector usb 3.0 era muy barato y facil de conseguir). Ese conector USB 3.0 "especial" realmente no es un USB como tal, solo utilizaron el conector, es una conexion directa a la propia FPGA y por lo tanto puedes conectarle un mando nativo del sistema que sea y la FPGA tiene acceso a el de manera directa sin lag. El unico problema es que al conectarse directamente a la FPGA no lo ve el linux que lleva instalado y que corre bajo la CPU, por lo tanto no puedes interactuar con los menus de la mister con el (tendrias que utilizar un segundo mando o teclado para eso) .
2.- La latencia de la propia conversion hdmi y la latencia de la propia tele la vas a tener si o si, la unica latencia que no tendras sera la de toda el procesado de escalado, colocar scanlines y demas movidas ya que esa parte la hace la propia FPGA en paralelo (exactamente igual que si tuvieses un circuito en hardware especifico para ello).
3.- No se como esta actualmente la implementacion de esos sistemas, si lo que te importa es jugar el de PSX ya hace bastante que funcionaba bastante bien (lo de sin errores lo dudo ya que es bastante temprano y nadie es perfecto, pero dudo que te des cuenta de alguno por tu cuenta ).
4.- No se a cuanto estan ahora mismo los packs. Pero vamos si no quisieras carcasa, si te da igual utilizar un hub usb, si no vas utilizar snac, etc solamente con la de-10 nano, un hub usb y una microsd puedes utilizar la mitad de los sistemas, aunque es sumamente recomendable. Incluso el core de NES requiere SDRAM.
Aqui tienes el listado de cores y si requieren el modulo de SDRAM o no:
https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Cores

Gracias por contestar. Para usar el puerto snac que hay que comprarle? Si se pilla sin carcasa, sin ram, y sólo con la salida hdmi, cuanto saldría aprox?

Yaripon escribió:

jimi escribió:

Yaripon escribió:Yo no termino de enterarme muy bien como van algunas cosas de este cacharro. Me genera una curiosidad tremenda, eso sí. Alguien podría resolverme algunas dudillas??
1. Los puertos usb falsos raros que con un adaptador conectas los mandos originales, se supone que no meten lag, no?
2. Hay algún montaje que permita sacar imagen hdmi en proporción correcta, 1080p scanlines y sin meter latencia extra?
3. Saturn y Ps1 van bien y sin errores?
4. En caso de ser correcta la opción 2, así a ojimetro sobre cuanto saldría un pack básico que pudiera mover al menos la Nes y que después a futuro se pudiera ampliar para que le funcione todo lo demás? (Porque tengo entendido que para las otras hay que meter expansiones de ram y no se si algo más).

1.- Ese es el puerto SNAC y en mi opinion el utilizar un conector USB 3.0 no fue la mejor decision y genera mucha confusion, pero es entendible el porque lo hicieron (reduccion de costes porque un conector usb 3.0 era muy barato y facil de conseguir). Ese conector USB 3.0 "especial" realmente no es un USB como tal, solo utilizaron el conector, es una conexion directa a la propia FPGA y por lo tanto puedes conectarle un mando nativo del sistema que sea y la FPGA tiene acceso a el de manera directa sin lag. El unico problema es que al conectarse directamente a la FPGA no lo ve el linux que lleva instalado y que corre bajo la CPU, por lo tanto no puedes interactuar con los menus de la mister con el (tendrias que utilizar un segundo mando o teclado para eso) .
2.- La latencia de la propia conversion hdmi y la latencia de la propia tele la vas a tener si o si, la unica latencia que no tendras sera la de toda el procesado de escalado, colocar scanlines y demas movidas ya que esa parte la hace la propia FPGA en paralelo (exactamente igual que si tuvieses un circuito en hardware especifico para ello).
3.- No se como esta actualmente la implementacion de esos sistemas, si lo que te importa es jugar el de PSX ya hace bastante que funcionaba bastante bien (lo de sin errores lo dudo ya que es bastante temprano y nadie es perfecto, pero dudo que te des cuenta de alguno por tu cuenta ).
4.- No se a cuanto estan ahora mismo los packs. Pero vamos si no quisieras carcasa, si te da igual utilizar un hub usb, si no vas utilizar snac, etc solamente con la de-10 nano, un hub usb y una microsd puedes utilizar la mitad de los sistemas, aunque es sumamente recomendable. Incluso el core de NES requiere SDRAM.
Aqui tienes el listado de cores y si requieren el modulo de SDRAM o no:
https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Cores

Gracias por contestar. Para usar el puerto snac que hay que comprarle? Si se pilla sin carcasa, sin ram, y sólo con la salida hdmi, cuanto saldría aprox?

Has probado a poner en un buscador DE10 Nano?

En los 3 primeros enlaces ya te salen webs de tiendas.

DJ Deu escribió:

Yaripon escribió:

jimi escribió:1.- Ese es el puerto SNAC y en mi opinion el utilizar un conector USB 3.0 no fue la mejor decision y genera mucha confusion, pero es entendible el porque lo hicieron (reduccion de costes porque un conector usb 3.0 era muy barato y facil de conseguir). Ese conector USB 3.0 "especial" realmente no es un USB como tal, solo utilizaron el conector, es una conexion directa a la propia FPGA y por lo tanto puedes conectarle un mando nativo del sistema que sea y la FPGA tiene acceso a el de manera directa sin lag. El unico problema es que al conectarse directamente a la FPGA no lo ve el linux que lleva instalado y que corre bajo la CPU, por lo tanto no puedes interactuar con los menus de la mister con el (tendrias que utilizar un segundo mando o teclado para eso) .
2.- La latencia de la propia conversion hdmi y la latencia de la propia tele la vas a tener si o si, la unica latencia que no tendras sera la de toda el procesado de escalado, colocar scanlines y demas movidas ya que esa parte la hace la propia FPGA en paralelo (exactamente igual que si tuvieses un circuito en hardware especifico para ello).
3.- No se como esta actualmente la implementacion de esos sistemas, si lo que te importa es jugar el de PSX ya hace bastante que funcionaba bastante bien (lo de sin errores lo dudo ya que es bastante temprano y nadie es perfecto, pero dudo que te des cuenta de alguno por tu cuenta ).
4.- No se a cuanto estan ahora mismo los packs. Pero vamos si no quisieras carcasa, si te da igual utilizar un hub usb, si no vas utilizar snac, etc solamente con la de-10 nano, un hub usb y una microsd puedes utilizar la mitad de los sistemas, aunque es sumamente recomendable. Incluso el core de NES requiere SDRAM.
Aqui tienes el listado de cores y si requieren el modulo de SDRAM o no:
https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Cores

Gracias por contestar. Para usar el puerto snac que hay que comprarle? Si se pilla sin carcasa, sin ram, y sólo con la salida hdmi, cuanto saldría aprox?

Has probado a poner en un buscador DE10 Nano?

En los 3 primeros enlaces ya te salen webs de tiendas.

Si pones de 10 Nano en el buscador salen en los 3 primeros enlaces opciones de 160, 260 y accesorios todo mezclado. Para alguien que no sabe del tema es bastante confuso saber si la opción buena es la de 160, la de 260, si con eso sirve, si hay que meter accesorios... De todas todas como no me la voy a pillar ahora pues cuando sea el momento ya me buscaré la vida.
Eso si, agradecerte la gran respuesta. "Pues búscalo en Google" es una respuesta que sirve para temas muy diversos, y ahora en estos tiempos también se puede ampliar con la también muy socorrida "pregunta en chat gpt". Creo que cuando preguntes por el foro algo que yo sepa, te recordaré esas maravillosas opciones.

Yaripon escribió:

DJ Deu escribió:

Yaripon escribió:
Gracias por contestar. Para usar el puerto snac que hay que comprarle? Si se pilla sin carcasa, sin ram, y sólo con la salida hdmi, cuanto saldría aprox?

Has probado a poner en un buscador DE10 Nano?

En los 3 primeros enlaces ya te salen webs de tiendas.

Si pones de 10 Nano en el buscador salen en los 3 primeros enlaces opciones de 160, 260 y accesorios todo mezclado. Para alguien que no sabe del tema es bastante confuso saber si la opción buena es la de 160, la de 260, si con eso sirve, si hay que meter accesorios... De todas todas como no me la voy a pillar ahora pues cuando sea el momento ya me buscaré la vida.
Eso si, agradecerte la gran respuesta. "Pues búscalo en Google" es una respuesta que sirve para temas muy diversos, y ahora en estos tiempos también se puede ampliar con la también muy socorrida "pregunta en chat gpt". Creo que cuando preguntes por el foro algo que yo sepa, te recordaré esas maravillosas opciones.

Bueno, solo hay ese tipo de placa, no hay otra, por lo que el margen de error es ir a la más barata.

Lamento que te sea tan lioso buscar las cosas por ti mismo, aunque pondría la mano al fuego que salvo los que se la han comprado con todo el kit hecho, la han comprado usando esa técnica.

Una pena que no hicieras ni puto caso al mensaje anterior que te puse, ahí te lo detallaba mucho mejor.

@Yaripon trinca en un vendedor de confianza
https://manuferhi.com/c/mister-fpga
Te faltaría la FPGA,carcasa(si no te gusta la que ofrece) y alimentador(5v 3A).

mcfly escribió:@Yaripon trinca en un vendedor de confianza
https://manuferhi.com/c/mister-fpga
Te faltaría la FPGA,carcasa(si no te gusta la que ofrece) y alimentador(5v 3A).

Si el solo quiere la placa.

https://www.digikey.es/es/videos/t/tera ... 0-nano-kit

mcfly escribió:No sé si es que no me explico bien....
Si yo diseño un circuito, y al cabo de los años,lo rediseño,ya sea simplificándolo por que la tecnología lo permite o por mis conocimientos,o por abaratar costes,caso de la mayoría de consolas,estamos hablando de un rediseño del circuito,digital y analógico.Que tendrán pequeñas diferencias de funcionamiento entre ellas,desde la bios,software e incluso funcionamiento.En ningún caso hablamos de emular la primera versión.Vamos,que el Clio del 2000 no emula al del 98.

En cuanto los fpga,decimos muy libremente que los cores están IMPLEMENTANDO la parte lógica de las consolas(a veces de una versión o dos,de la placa de una consola) al dedillo.Esos "ajustes finos" y esos comportamientos aleatorios(que un juego vaya fino y otro no)en un mismo core,me da que pensar, que hay partes lógicas emuladas.
De la parte analógica no hay nada a implementar.Solo emular,por ejemplo,el sonido o la salida de video.

Casi todos los cores,llevan opciones que no llevan el sistema original,pausa,savestates,rebobinar...que modifican la rom y el sistema.Hay cores muy poco precisos,que me gustaría saber que porcentaje de implementación lógica llevan.

En el mejor de los casos,se está IMPLEMENTANDO(programando la fpga) la parte lógica de una placa,con variaciones custom e intentando afinar el comportamiento de la parte analógica.

Y si se implementa 1:1 la parte lógica,porque se conoce su esquema,por qué siempre hay betas con fallos?.No tendría que implementarse a la primera,teniendo el esquema delante?,o es que,como digo,hay ajuste fino?.

@AxelStone no sé que me quieres decir con lo del msx.Todas las consola,microordenadores,han tenido rediseños de
placas a base de chips custom.Si el creador de una placa(quien mejor que él)es capaz de implementarla en una fpga y conservar la parte analógica),pues ok,donde está el problema?.Has visto fpgas en alguna consola?.,O has visto chips comerciales y chips custom?.

gynion escribió:Nishi también le dio el visto bueno a MSXVR. No sé, vosotros veréis, pero creo que es mejor disfrutar de Mister sin pensar que es más de lo que realmente es.

Y eso es pura emulación.

En fín,volviendo a la MISTER,no hay nadie por aquí,que tenga el core de N64,para poder probar el romset?

Todos los ejemplos que pones tu de FPGA te pongo exactamente los mismos con revisiones de consolas u ordenadores y son exactamente el mismo ejemplo... pero tu en un caso lo llamas emulacion mientras que en el otro no lo consideras ni por asomo xD. Ahi tienes la contradiccion y hasta que la des resuelto tu solo no podemos hacer absolutamente nada el resto .

Por cierto, hay juegos que funcionaban solo en ciertas revisiones de consolas porque no son hardware exactamente iguales, quiere decir eso que esas revisiones emulan? pues claro que no xD. La snes one chip lleva componentes hardware muy diferentes a la original, es eso emulacion? pues claro que no.

Y por cierto, supongo que el trabajo que hacia furteek de decapar los chips de neogeo para poder intercambiarlos por los originales en cuanto se fuesen jodiendo (implementandolos tanto en FPGA como en ASIC segun convenga por precio) seria un trabajo de convertir un hardware original en uno emulado no? xD.

@Yaripon Mejor que preguntes por ahi o busques un poco, porque yo la compre hace años, asi que no estoy muy puesto a como esta actualmente.
Ademas creo que yo y muchos en este hilo ya nos molestamos bastante hace años en explicar lo que era y en comentar que estaba a muy buen precio para comernos encima contestaciones de que era carisima y una estafa a ese precio, que mejor se esperaban a que bajase de precio xD. Lo triste es que pasaron los años, cuesta ahora literalmente el doble y ni siquiera se molestaron en querer entender lo que es una FPGA a dia de hoy :/.

Yo suelo decir que aprender lleva su tiempo (a algunos le llevara mas y a otros menos), pero aun con todo el tiempo del mundo no se aprende absolutamente nada si no se pone el mas minimo interes en ello .

@jimi el problema lo tengo yo,ok.Ya ves que soy yo contra todos.
Que tal los cores de x68k o pc88?.
La última vez que jugué al ghost n goblins en mister,seguía el glicht del mapa y el bug del scroll,a partir de la cuarta pantalla,aleatoriamente(cosa que no ocurre en emuladores,por cierto).Pero ya sabemos que
Eso no puede ser,es IMPLEMENTACIÓN, y la parte lógica es 1:1(será fallo de las placas originales).
O igual me falla a mi,porque lo llamo emulación.

A los que decís que comprar la mister siendo novatos en el tema es fácil, y que el precio es "buscar en Google y ta está".
Estoy seguro que en estas mierdas hay diferencias que justifiquen el precio, pero si llegas teniendo pocas nociones del tema y ves esto, te quedas con el culo torcido:
Terrasic cosa de 10 a 160€
https://www.digikey.es/es/products/deta ... 66/6230089
De10 en la misma tienda, a 130€
https://www.digikey.es/es/products/deta ... 82/2625112
Y aquí a 250€
https://www.digikey.es/es/products/deta ... 8/10229608
Cual es la correcta? Ni puta idea.
Pero si vamos a los accesorios ya la cosa es más divertida:
El pack de accesorios aquí en aliexpress está a 50€
https://a.aliexpress.com/_EJYznoT
Pero en otras webs la venden al divertido precio de 200€. Diferencias? Ni puñetera idea.
Y después ya, si la quieres comprar tu montadita pues... 600€. De donde salen esos 600€, porque a mi en piezas no me sale esa suma? Ni idea tampoco.

Por mi parte creo que voy a pasar del tema, al menos de momento. Veo que alguna peña por aquí dice que no es tan impresionante como cuentan, y la más ligera y remota duda que pueda haber, hablando sobre todo de estos precios, me echa mucho para atrás. Además en mi caso aún por encima ya tengo las consolas que me interesan, sería sobre todo para poder jugarlas en la tv plana sin scalers y toda la parafernalia, y si realmente cuesta 600€ (si por lo que sea la placa de 130€ no es la correcta y los accesorios de Aliexpress no sirven por X) me parece mucha pasta sólo por jugar las consolas por hdmi. Para alguien que no tenga ninguna genial, pero para los que las tenemos casi todas pues... Si la placa y accesorios barata sirviera, pues podía ser planteable. Pero entiendo que si es cacharro lo venden montado a 600€ no será porque todo el mundo es idiota, y esas piezas que vi yo no serán, porque según mis cuentas aproximadas saldría como a 300€ el cacharro.

Yaripon escribió:A los que decís que comprar la mister siendo novatos en el tema es fácil, y que el precio es "buscar en Google y ta está".
Estoy seguro que en estas mierdas hay diferencias que justifiquen el precio, pero si llegas teniendo pocas nociones del tema y ves esto, te quedas con el culo torcido:
Terrasic cosa de 10 a 160€
https://www.digikey.es/es/products/deta ... 66/6230089
De10 en la misma tienda, a 130€
https://www.digikey.es/es/products/deta ... 82/2625112
Y aquí a 250€
https://www.digikey.es/es/products/deta ... 8/10229608
Cual es la correcta? Ni puta idea.
Pero si vamos a los accesorios ya la cosa es más divertida:
El pack de accesorios aquí en aliexpress está a 50€
https://a.aliexpress.com/_EJYznoT
Pero en otras webs la venden al divertido precio de 200€. Diferencias? Ni puñetera idea.
Y después ya, si la quieres comprar tu montadita pues... 600€. De donde salen esos 600€, porque a mi en piezas no me sale esa suma? Ni idea tampoco.

Por mi parte creo que voy a pasar del tema, al menos de momento. Veo que alguna peña por aquí dice que no es tan impresionante como cuentan, y la más ligera y remota duda que pueda haber, hablando sobre todo de estos precios, me echa mucho para atrás. Además en mi caso aún por encima ya tengo las consolas que me interesan, sería sobre todo para poder jugarlas en la tv plana sin scalers y toda la parafernalia, y si realmente cuesta 600€ (si por lo que sea la placa de 130€ no es la correcta y los accesorios de Aliexpress no sirven por X) me parece mucha pasta sólo por jugar las consolas por hdmi. Para alguien que no tenga ninguna genial, pero para los que las tenemos casi todas pues... Si la placa y accesorios barata sirviera, pues podía ser planteable. Pero entiendo que si es cacharro lo venden montado a 600€ no será porque todo el mundo es idiota, y esas piezas que vi yo no serán, porque según mis cuentas aproximadas saldría como a 300€ el cacharro.

Los enlaces que pones no son la DE-10 nano, son otros modelos de FPGA que no sirven para montar una MiSTer.

Si quieres una guía sencilla y básica, puedes mirar esta misma. Si quieres una configuración completa, los vendedores españoles más famosos son Antonio Villena y ManuFerHi, el primero hace placas personalizadas con diseño bonito y el segundo sigue los estándares MiSTer, ambas funcionan correctamente (excepto el infame core de Saturn con las de Villena, pero lo están arreglando).
Si te la quieres montar a mano, mira las partes en la configuración de ManuFerHi y haz números. Ya te adelanto que lo caro es la DE-10 Nano, el resto son cosa de 30-60€ por cacharro y son todos opcionales.

Por utilidad, pues si tienes las consolas originales, las ventajas que vas a tener es que saca señal digital hdmi sin conversores ni input lag, y te reemplaza los flashcart de todas las máquinas. Solo por Neogeo y CPS2 ya vale la pena, aparte de las placas arcade que te ahorras tener en casa. Si aún así esperas que aporte algo más, tiene cores de microordenadores pero si eres como yo que te dan igual, tendrás que valorar si la necesitas o no.

A mi me interesó porque me permitía meterla en una recreativa por jamma y me ahorraba comprar placas que se romperán más pronto que tarde. En cualquier otro caso, sigo prefiriendo las consolas originales y un emulador en un buen PC te hace hasta mejor servicio porque cubre muchos más sistemas y juegos. No cuento la raspberry porque digan lo que digan, ni la compararía con MiSTer o con un PC de verdad

@Yaripon , ahora mismo gastarme 500€ en una Mister completa me parece una soberana gilipollez. Sólo la De10 Nano te vale más de 300€. Si a eso le sumas otros extras te puedes ir perfectamente a cerca de 400. Antes por 200-250€ tenías el setup completo, así todavía merecía la pena embarcarse, ¿pero a los precios actuales? Desde mi punto de vista ni jarto de vino.

Que oye, ¿hay diferencias frente a los emuladores tradicionales? En algunos casos sí, pero ni son tantas como algunos quieren hacernos creer ni mucho menos son tan marcadas como para justificar un gasto tan elevado.

La única ventaja de la MiSTer actualmente es que responde igual que lo haría el sistema original a modo de input.

Pero en su forma de funcionar, nadie sabría decir si es más fiel que un emulador de software ya que la emulación tradicional está tan avanzada que si te lo miras fríamente estamos en un punto que comparativamente es inapreciable a día de hoy.

Y ese es el otro debate que seguirá abierto: ¿te gastarías lo que cuesta? Como todo producto de nicho tiene su público pero no va a ser algo de masas. Gastarse 500€ en un capricho pues mira, con eso le haces un buen apaño al PC.

A mi me encantan las FPGAs, pero reconozco que me costaría mucho gastar lo que cuesta una Mister. Sobre emulación pues mira, un buen RGBuntu corriendo en una pantalla CRT o incluso una humilde RPi corriendo RGB-Pi, dan resultados más que dignos.

La tecnología debe estar muy bien como alternativa, si buscas determinadas características concretas con mucho afán y te las da, pero la veo lejos de ser una opción definitiva, basándome en reviews y en las opiniones de los que sois usuarios. No creo que haya hecho olvidarse a la mayoría de la emulación convencional, que es más útil y con mayores posibilidades.

Para los cansinos de lo que es una FPGA

jimi escribió:@mcfly Cuando se implementan los circuitos en una nueva revision de una consola, por ejemplo una SNES one chip o una megadrive 2 cual es la funcion que realiza ese nuevo circuito digital? emulacion? yo aun no he visto a nadie que se refiera a estas nuevas revisiones como que emulan juegos o lo que sea xD. Y si, la funcion que realizan es la de permitirte jugar a juegos de esos sistemas, pero en mi opinion no emulan nada (por mucho que tecnicamente estirando un poco el chicle se pudiese llamar emulacion a eso).

El ejemplo que pones depende de la revisión de la consola. PS1 y su versión Slim tienen la misma placa y componentes de ahí que no sea una emulación ya que es la misma consola, pero una lleva la fuente de alimentación dentro y la otra no.

Con PS2 la cosa es más compleja ya que en los modelos fat y los primeros Slim son sobre el papel la misma consola con el único cambio de que la CPU y GPU están integrados en un solo chip, pero con las últimas Slim de PS2 ya es emulación, ya que se elimina el R3000 de PS1 que se usaba para ejecutar juegos de PS1 aparte de ciertas funciones de PS2 y se sustituye por un chip ARM que emula sus funciones, lo que a su vez provoca que ciertos juegos de PS2 de problemas en las últimas Slim, pero funcionan perfectamente en las demás versiones.

@ALCAMJI Muy buen video y sin entrar en guerras absurdas.

AxelStone escribió:@ALCAMJI Muy buen video y sin entrar en guerras absurdas.

Exacto, que para guerras absurdas ya tenemos la del ZXTres. Tu ya me entiendes.

@ALCAMJI lo que explicas sobre ps2,es de sobra conocido.Lo mismo que lad DS lite,llevaban una gba en su pcb.O la primera ps3 de 60gigas,llevaba una ps2 también.Pero es bueno recordarlo.
Sobre el video,no creo que haga cambiar mucho a la gente de fpga = emulación o implementación.
Pero nunca sobra la info.

mcfly escribió:@jimi el problema lo tengo yo,ok.Ya ves que soy yo contra todos.
Que tal los cores de x68k o pc88?.
La última vez que jugué al ghost n goblins en mister,seguía el glicht del mapa y el bug del scroll,a partir de la cuarta pantalla,aleatoriamente(cosa que no ocurre en emuladores,por cierto).Pero ya sabemos que
Eso no puede ser,es IMPLEMENTACIÓN, y la parte lógica es 1:1(será fallo de las placas originales).
O igual me falla a mi,porque lo llamo emulación.

Y ese es el problema, te dicen la verdad, con ejemplos objetivos y te sales otra vez por las ramas intentando justificar la absurdez de llamar emulacion si esta hecho con FPGA y negarte a llamar emulacion si esta hecho tanto con componentes discretos como con ASICs?
En los 3 casos no son 1:1. Es como cuando te preguntan de que color es el caballo blanco de santiago y respondes, que santiago es una ciudad porque no sabes de que color es, vaya tela xD.

Es mas, ya que tengo unos minutejos de espera, te pongo un ejemplo muy claro aunque pueda parecer algo confuso para algunos. Si tu implementas en una FPGA un x86, pero luego coges y en ese x86 corres un emulador de NES? Que estas implementado o emulando con la FPGA?. Pues creo que es bastante obvio que estas implementando un x86 (y no tiene porque ser 1:1, ademas cual es el 1:1 de un x86? a saber xD).
Que alguno te pueda decir que estas emulando una NES... si tecnicamente podrias decir que tu como usuario estas emulando una NES (y porque el termino se ha estirado hasta el infinito ya a estas alturas pero bueno), pero no podrias decir que la FPGA esta emulando una NES porque no es asi, la FPGA esta implementando un x86 y punto . Y este mismo ejemplo podrias cambiar FPGA por ASIC o por componentes discretos y seria exactamente lo mismo .

@jimi no sé,igual no me sé explicar.Pero no soy yo el que no acepta la palabra emulación en fpgas y se altera.Ni el que no ve errores en supuestos cores 1:1.
Explícame la verdad,porque me he perdido.Porque sigo viendo glitches,bugs....donde en las consolas o placas arcade,no los veo.
Llámalo emulación,implementación o cycle le accurate.

@mcfly en realidad la DS lleva 2 CPU de GBA, aunque al doble de velocidad, que al ejecutar un juego de GBA usas solo una de las CPU y a la mitad de velocidad para evitar problemas.

Más interesante es el modo GBA de la 3DS que usa la opción del procesador ARM11 para ejecutar código del ARM7 de GBA.

mcfly escribió:@jimi no sé,igual no me sé explicar.Pero no soy yo el que no acepta la palabra emulación en fpgas y se altera.Ni el que no ve errores en supuestos cores 1:1.
Explícame la verdad,porque me he perdido.Porque sigo viendo glitches,bugs....donde en las consolas o placas arcade,no los veo.
Llámalo emulación,implementación o cycle le accurate.

En las Mister hay cores 1:1 y cores que no lo son no?

O sea que yo sepa no todos tienen glitches, que por cierto nada tiene que ver con el cicle accurate, puede haber un core cicle accurate y tener glitches graficos.

@naxeras Y por qué no son 1:1 y por qué otros se afirma que son 1:1?.La respuesta sencilla es que tienen la información sobre los circuitos y en otros casos no.
Lo del cycle accurate no lo he entendido(salvo que en la consola,también los tenga).
Yo ya he puesto un caso de un supuesto core 1:1,que no funciona como debería.Pero hay gente que no quiere aceptar que sigue habiendo diferencias,tanto con emulación por software como con implementación por software.
En ambos casos hay cosas muy logradas.

Por cierto,world driver championship está funcionando en mister.Con glitches por todos lados,de momento.

https://youtu.be/ufnWxVrpyIU?si=F7tx_fnDAj6NWxHZ

@mcfly La ultima vez que toqué la Mister la Neogeo no iba al 100% cuando mucha gente decía que sí, es que yo veo que la Mister está muy mitificada , ya sabes lo que pasó con mi discusión sobre el sonido de la CPS1 pero vamos lo dejé porque no quería discutir más.

Yo al final la Mister al cajón prefiero emulación tradicional, la diferencia es casi inapreciable y tengo más opciones aparte de ser más baratas, creo que la Mister viene mejor en una CRT pero no es la venida de cristo como muchos vaticinaban.

Saludos.

AlterNathan escribió:@mcfly La ultima vez que toqué la Mister la Neogeo no iba al 100% cuando mucha gente decía que sí, es que yo veo que la Mister está muy mitificada , ya sabes lo que pasó con mi discusión sobre el sonido de la CPS1 pero vamos lo dejé porque no quería discutir más.

Yo al final la Mister al cajón prefiero emulación tradicional, la diferencia es casi inapreciable y tengo más opciones aparte de ser más baratas, creo que la Mister viene mejor en una CRT pero no es la venida de cristo como muchos vaticinaban.

Saludos.

El core de Neogeo ha mejorado mucho durante los últimos meses. De hecho todos los issues abiertos en GitHub se han cerrado, bien por haber sido corregidos o porque también ocurrían en el hardware original. Incluso se ha añadido Neogeo CD.

Un saludo.

mcfly escribió:Por cierto,world driver championship está funcionando en mister.Con glitches por todos lados,de momento.

https://youtu.be/ufnWxVrpyIU?si=F7tx_fnDAj6NWxHZ

Pues sin que sea una prueba irrefutable, si que muestra que de estar implementando las instrucciones de microcódigo del RCP como decía el creador del core (como se aseguraba aquí), naranjas de la china.
Si realmente se estuviera implementando el RSP, el WDC estaría funcionando bien, sin glitches. Pero como tiene microcódigos personalizados distintos a los estandar del SDK de Nintendo, suele haber fallos hasta crear parches o funciones ajustadas al juego.
De hecho en el vídeo mencionan que los juegos de Nintendo van perfectos, los de terceros tienen glitches. ¿Coincidencia? No lo creo...

Es decir, que más que implementar el hardware en una FPGA, se esta adaptando el código de un emulador al código del FPGA.
Que repito el disclaimer: eso no quita que siga siendo un trabajazo tremendo y una proeza meterlo en un FPGA, pero si le quita al core fidelidad con el original.
Tampoco es de extrañar que no este implementando el RSP, en la web de recursos para el desarrollo de N64 hay un manual de programación del RSP que tiene 330 páginas. Es bastante comprensible que con esa cantidad de información, no sale un RSP implementado en FPGA en un par de meses sin tomar alguna clase de atajo.

Igualmente es bueno que exista un core con el que poder jugar a una gran cantidad de juegos de N64 sin problemas. Para los quisquillosos el hardware original todavía es asequible, y para quien no esta la emulación oficial del Switch Online o de los emuladores de la comunidad.

Más novedades del core/emulador imposible.

@DJ Deu puse ese video hace dos dias.
@EMaDeLoC huele mal,sí.Pero bueno,al final pase lo que pase,será en los circulos de expertos, una implementación 1:1.

mcfly escribió:@DJ Deu puse ese video hace dos dias.
@EMaDeLoC huele mal,sí.Pero bueno,al final pase lo que pase,será en los circulos de expertos, una implementación 1:1.

Revisa la fecha de subida del vídeo.

DJ Deu escribió:

mcfly escribió:@DJ Deu puse ese video hace dos dias.
@EMaDeLoC huele mal,sí.Pero bueno,al final pase lo que pase,será en los circulos de expertos, una implementación 1:1.

Revisa la fecha de subida del vídeo.

No te falta la razón.

EMaDeLoC escribió:

mcfly escribió:Por cierto,world driver championship está funcionando en mister.Con glitches por todos lados,de momento.

https://youtu.be/ufnWxVrpyIU?si=F7tx_fnDAj6NWxHZ

Pues sin que sea una prueba irrefutable, si que muestra que de estar implementando las instrucciones de microcódigo del RCP como decía el creador del core (como se aseguraba aquí), naranjas de la china.
Si realmente se estuviera implementando el RSP, el WDC estaría funcionando bien, sin glitches. Pero como tiene microcódigos personalizados distintos a los estandar del SDK de Nintendo, suele haber fallos hasta crear parches o funciones ajustadas al juego.
De hecho en el vídeo mencionan que los juegos de Nintendo van perfectos, los de terceros tienen glitches. ¿Coincidencia? No lo creo...

Es decir, que más que implementar el hardware en una FPGA, se esta adaptando el código de un emulador al código del FPGA.
Que repito el disclaimer: eso no quita que siga siendo un trabajazo tremendo y una proeza meterlo en un FPGA, pero si le quita al core fidelidad con el original.
Tampoco es de extrañar que no este implementando el RSP, en la web de recursos para el desarrollo de N64 hay un manual de programación del RSP que tiene 330 páginas. Es bastante comprensible que con esa cantidad de información, no sale un RSP implementado en FPGA en un par de meses sin tomar alguna clase de atajo.

Igualmente es bueno que exista un core con el que poder jugar a una gran cantidad de juegos de N64 sin problemas. Para los quisquillosos el hardware original todavía es asequible, y para quien no esta la emulación oficial del Switch Online o de los emuladores de la comunidad.

La implementación del RSP está en desarrollo, por eso ves esos errores en el WDC.
Pero la idea es que corran todos los microcódigos sin problemas: de hecho, muchos de los que NO son de Nintendo ya lo hacen.

Elazul escribió:La implementación del RSP está en desarrollo, por eso ves esos errores en el WDC.

Voy a explicar con profundidad los motivos de mis preocupaciones.
El RSP es un microprocesador, basicamente es un R4000 con cosas quitadas y añadidas, como un coprocesador de vectores y la unidad de rasterización RDP.
Tiene su conjunto de instrucciones que como la de cualquier procesador hacen operaciones y no tienen mucha complejidad: copia un dato a un registro, sumalo con esto, restalo con aquello, comparalo con este, salta a la próxima instrucción, etc. Si alguien ha echado un vistazo a lenguaje ensamblador ya sabe como va esto.
Lo que no tienen las instrucciones por sí solas son cosas complejas como rota una imagen, compara el z-buffer, etc. Eso se consigue con un conjunto completo de instrucciones, los famosos microcódigos.

Tenía razón Robert, el creador del core, en que si se implementa el RSP da igual lo que se ejecute, se ejecutará y punto, sin HLE ni emulación ni cosas así, y es cierto.
Es decir, si se implementa las instrucciones que maneja el RSP, una vez esten todas listas, correrá cualquier juego sin problemas, sin importar el microcódigo que se ejecuta.
Y ahí esta el primer escollo: eso no ha ocurrido nunca.
Es decir, puedo entender que haya glitches porque resulte que al hacer una comparación o una operación concreta, resulte que hay excepciones, desbordamientos, un registro haciendo algo que no debería hacer... Eso sería normal en un desarrollo de este tipo, pero pasaría en varios juegos a la vez, ya que todos los juegos, sin importar si los microcódigos que ejecutan son los oficiales o personalizados, estan ejecutando las instrucciones del RSP que son comunes a todos los juegos.
Sin embargo no estamos viendo en el desarrollo del core que todos los juegos funcionen y tengan glitches comunes, como ocurriría si se estuviera implementando el conjunto de instrucciones del RSP. Lo que hemos ido viendo es que los juegos desarrollados con SDK oficiales han sido jugables y practicamente a la perfección antes que otros juegos con microcódigos personalizados.

Es más, las librerias de microcódigos oficiales separan el rasterizado de triángulos entre los que llevan z-buffer y los que no, además de otros modos de dibujado. Esa distinción del manejo del z-buffer solo se encuentra en las librerias, no en las instrucciones del RSP. Después de mirarme por encima el manual sobre el RSP, no hay distinción alguna entre framebuffer y z-buffer para el RSP, son simples accesos a RAM con direcciones distintas. Es decir, no hay un conjunto específico y concreto de instrucciones del RSP dedicadas al z-buffer, es una función creada con las librerias de microcódigos. ¿Y como ha ido el desarrollo del core? Pues antes no había z-buffer y luego si, como si en el core se estuviese implementando funciones de las librerias del SDK en vez de las instrucciones del RSP.

De hecho hubo una etapa en la que el juego de Wave Race mostraba el agua como una malla en vez de los polígonos pintados. Bueno, pues lo de dibujar mallas es una función de las librerias oficiales:

Lo podeis ver en la página 91 de este manual oficial en PDF.
Eso significa que se ha cambiado una función del SDK por otra a la hora de ejecutar el juego, algo que no sucedería de implementarse el RSP pues no existe la instrucción "dibuja una malla".

Lo resumo al máximo para que se entienda: si se implementase el RSP, una vez puestas todas las instrucciones, todos los juegos, tuviesen o no microcódigos personalizados, se ejecutarian, y de haber algún bug, todos tendrían glitches comunes.
Pero si lo que se hace es implementar las librerias del SDK, los juegos van mejorando poco a poco en imagen y jugabilidad conforme se van implementando cada una de las librerias, que es justo lo que ha ido ocurriendo con el desarrollo del core.

Y por aclarar, quiero separar cosas como el rasterizador, el filtrado de texturas, etc, porque son partes físicas del RCP que existen dentro del procesador, no son como el z-buffer que se crea y gestiona basicamente por software, ya sea por libreria de microcódigos o a lo bruto con la CPU.

Elazul escribió:Pero la idea es que corran todos los microcódigos sin problemas: de hecho, muchos de los que NO son de Nintendo ya lo hacen.

Muchos de los que no son de Nintendo también usan el SDK oficial sin cambiar nada. Pero hay juegos que si tienen microcódigos personalizados como el WDC o el Beetle Adventure Racing que en el vídeo compartido anteriormente sí tienen glitches. Cosa que, repito, no pasaria si se estuviese implementando el RSP y no las librerias.

Por esto a mí me da toda la impresión de que se ha programado un emulador de N64 dentro del FPGA que recurre a identificar y emular (valga la redundancia) funciones del SDK oficial, no la circuitería lógica de la CPU y GPU de la consola. Ojo, sigue siendo un trabajazo, pero la idea del Mister es implementar la circuiteria lógica de los procesadores de las consolas, no meter un emulador que ha hecho mil atajos para saltarse ciertas complejidades y que aún así requiere parches para juegos concretos.

Creo que así queda claro que mis preocupaciones tienen base fundamentada.

EMaDeLoC escribió:

Elazul escribió:[...]

Por esto a mí me da toda la impresión de que se ha programado un emulador de N64 dentro del FPGA que recurre a identificar y emular (valga la redundancia) funciones del SDK oficial, no la circuitería lógica de la CPU y GPU de la consola. Ojo, sigue siendo un trabajazo, pero la idea del Mister es implementar la circuiteria lógica de los procesadores de las consolas, no meter un emulador que ha hecho mil atajos para saltarse ciertas complejidades y que aún así requiere parches para juegos concretos.

Creo que así queda claro que mis preocupaciones tienen base fundamentada.

No sé de qué te extrañas. Con el core de PSX se "inspiró fuertemente" en Duckstation mientras que con éste se está "inspirando" en Ares.

Blanco y en botella.

El día que descubra que gran parte de los arcades de MiSTer de debuggean en MAME me se de uno que le explotará la cabeza.

@EMaDeLoC

Buenas, no creo que se esté haciendo como dices.

Tu basicamente lo que indicas es que se está implementando un GlideN64 y eso no tiene ningún sentido.

Se estarán implementando como si fuera un agrilion más bien, o sea si implementan las instrucciones a bajo nivel, el tema es que si hay diferentes partes que implementar, puedes ver la información de las partes que compone en el RDP en parallel RDP o en angrilion.

No se está implementando el Z-Buffer, se implementa el Blender que es el que permite z-buffer o el antialiasing, si eso no esta del todo implementado esos efectos no funcionan (de hecho no funcionan ahora mismo).

Me baso en esto porque por ejemplo hemos tenido un montón de tiempo sin filtrado de texturas porque es parte del Texture Unit y no estaba del todo implementado.

No tiene sentido que te pongas a hacer un RDP HLE porque no te da ventaja a la hora de implementar eso en uina FPGA, lo chulo del HLE es que los microcodigos los "traducias" a instrucciones OpenGL, DirectX, Glide, Vulkan o lo que sea y claro de esta forma iba mucho más rapido el emulador, pero tu en las Mister no tienes OpenGl, ni DirectX ni ningun API a la que traducir ese microcodigo.

En cuanto a la CPU pues lo mismo habran implentado las instrucciones tal cual.

Que se use un emulador como base para hacer un Core FPGA es lo más normal del mundo, no se tiene decapados todos los chips y no tienes todos los esquemas perfectos asi que haces una implementación basada en el comportamiento.

Yo os lo digo desde mi observación y como funciona un emulador de N4 no tengo ni mister ni nada.

EDITO: He encontrado un link donde también aparecen las partes del RDP y en español:

https://www.copetti.org/es/writings/con ... ntendo-64/

Fijaos como durante la vida del emulador se ha ido implementando parte a parte y los defectos van acompañados a esto, cosa que es lo normal, no tienen ningun sentido hacer un HLE porque no hay instruciones target a las que derivar.

Un Saludo.

DJ Deu escribió:El día que descubra que gran parte de los arcades de MiSTer de debuggean en MAME me se de uno que le explotará la cabeza.

Los fallos que haya en un core no mejora ni empeora la situación de otro core.
Los aciertos o fallos que haga un desarrollador no influyen ni en lo positivo ni en lo negativo en el trabajo de otro desarrollador que trabaja en un proyecto distinto al de otro.
Es completamente normal que en un desarrollo surjan bugs. No todo esta bien documentado, ni toda la documentación original y oficial es, a veces, del todo correcta.

No sé cual era el objetivo del comentario, pero no aporta nada.

naxeras escribió:No se está implementando el Z-Buffer, se implementa el Blender que es el que permite z-buffer o el antialiasing, si eso no esta del todo implementado esos efectos no funcionan (de hecho no funcionan ahora mismo).

Me baso en esto porque por ejemplo hemos tenido un montón de tiempo sin filtrado de texturas porque es parte del Texture Unit y no estaba del todo implementado.

Precisamente he comentado que diferenciaba entre las partes físicas del RCP y lo que no:

EMaDeLoC escribió:Y por aclarar, quiero separar cosas como el rasterizador, el filtrado de texturas, etc, porque son partes físicas del RCP que existen dentro del procesador, no son como el z-buffer que se crea y gestiona basicamente por software, ya sea por libreria de microcódigos o a lo bruto con la CPU.

En cuanto al blender del RDP, si se consulta el manual de programación (pág. 205) se puede ver que, tal y como indica su nombre, fusiona los nuevos pixeles creados con los existentes en el frambuffer creando transparencias, antialiasing, niebla y, efectivamente, z-buffering, pero a todos los efectos el blender es un comparador al que se le pasan unos parámetros a comparar y arroja un resultado, pero no crea los datos necesarios, se crean en pasos previos del RSP y el RDP.

naxeras escribió:No tiene sentido que te pongas a hacer un RDP HLE porque no te da ventaja a la hora de implementar eso en uina FPGA, lo chulo del HLE es que los microcodigos los "traducias" a instrucciones OpenGL, DirectX, Glide, Vulkan o lo que sea y claro de esta forma iba mucho más rapido el emulador, pero tu en las Mister no tienes OpenGl, ni DirectX ni ningun API a la que traducir ese microcodigo.

No he mencionado nunca que se haga de ese modo. Lo que he dicho es que se estará usando un emulador de base para codificarlo a FPGA. Es decir, convertir un código en circuitería lógica, cosa que es totalmente factible en ambas direcciones. Y la mayoría de emuladores aprovechan el SDK oficial para tomar atajos, ya que la inmensa mayoría de juegos desarrollados por la consola usan el SDK integro (aunque hay un par de versiones de este) y solo unos pocos tienen sus propios microcódigos.

Y aunque no se tenga en la Mister OpenGL o DirectX, se puede crear un rasterizador y un filtrador de texturas a propósito y medida de cada core. De hecho la De-10 nano no tiene motor de sprites y bien que funcionan las consolas con sprites.

En cualquier caso eso no explica el porqué el Wave Race se pudo ver con malla siendo una función exclusivamente generada por librerias de microcódigos y no por el Color Combiner, el Blender o cualquier otra parte del RDP.

naxeras escribió:Que se use un emulador como base para hacer un Core FPGA es lo más normal del mundo, no se tiene decapados todos los chips y no tienes todos los esquemas perfectos asi que haces una implementación basada en el comportamiento.

No, si a mi me parece bien que se parta de un emulador, pero eso le va a restar fidelidad ya que la mayoría de emuladores toman atajos, excepto unos pocos que son cycle accurate o fieles a la circuitería lógica. Y entiendase que la Mister se esta vendiendo sobretodo por la "fidelidad con el hardware original", aunque luego el propio creador del core de N64 le meta a su core de PSX las mismas funciones de filtrado de texturas, widescreen, etc que los últimos emuladores...

Y sí existe un decapado del RCP, creo que pedido por Marshall, uno de los gurús de la consola:


Aparte de todo el código FPGA del RDP que se filtró cuando hicieron el pirateo masivo a Nintendo hace unos años y con el que se podría hacer un clon 1:1 de la consola por FPGA. El problema es que es propietario y la demanda que metería Nintendo sería de las épicas.

naxeras escribió:Fijaos como durante la vida del emulador se ha ido implementando parte a parte y los defectos van acompañados a esto, cosa que es lo normal, no tienen ningun sentido hacer un HLE porque no hay instruciones target a las que derivar.

En realidad si hay instrucciones target, o si no el primer emulador de la consola que funcionaba por HLE no habría existido. Los microcódigos se deben cargar al RSP para que los ejecute, así que solo hay que ver cuando lo hace el juego y de qué libreria del SDK son.

EMaDeLoC escribió:No sé cual era el objetivo del comentario, pero no aporta nada.

¿Por qué? yo veo que aporta un dato.

EMaDeLoC escribió:En realidad si hay instrucciones target, o si no el primer emulador de la consola que funcionaba por HLE no habría existido. Los microcódigos se deben cargar al RSP para que los ejecute, así que solo hay que ver cuando lo hace el juego y de qué libreria del SDK son.

No, el primer emulador HLE transformaba las instrucciones del SDK a GLIDE, en Mister a que las transformas?

Que se esté basando en un emulador no quiere decir que se esté basando en implementar microcodigos como dices, se está haciendo lo que hace angrilion.

En cuanto a que no son partes físicas, si lo son, lo puedes ver en el link que he puesto, no se que tiene que ver el manual del programador aqui cuando que tiene que ver como se programa a como se hace por debajo.

Es como si te digo que no hay un teselador fisico porque en el manual de programador se lanza una instrucción y ale.

Claro que tiene partes en concreto el RDP y puedes verlo en el plugin de angrilion o en el de parallel, auqneu Paralell lo hace con shaders y angrilion por CPU.

Lo que quiero decir es que no tiene pinta que se esté emulador microcodigos de ningun SDK si no lo que hay por debajo porque ademas se ven las partes descritas en el link que he puesto.

naxeras escribió:No, el primer emulador HLE transformaba las instrucciones del SDK a GLIDE, en Mister a que las transformas?

No, el emulador HLE no las transformaba en nada. Reconocia el microcódigo y sus parametros, por ejemplo un triángulo transparente, y ejecutaba la librería Glide con esos parámetros y el resto de datos necesarios.
En cuanto a lo que hace la Mister, lo he puesto:

EMaDeLoC escribió:Y aunque no se tenga en la Mister OpenGL o DirectX, se puede crear un rasterizador y un filtrador de texturas a propósito y medida de cada core. De hecho la De-10 nano no tiene motor de sprites y bien que funcionan las consolas con sprites.

Si estas partiendo de un emulador de PC, la mayoría tienen algo de HLE para pasarle los triángulos al DirectX u OpenGL de turno. Pero como evidentemente la Mister no tiene, se ha de crear un rasterizador, filtrado de texturas y lo que se necesite. Es más complejo, pero también se consigue algo más fiel desde el principio.

naxeras escribió:Que se esté basando en un emulador no quiere decir que se esté basando en implementar microcodigos como dices, se está haciendo lo que hace angrilion.

Angrylion es un emulador...

naxeras escribió:En cuanto a que no son partes físicas, si lo son, lo puedes ver en el link que he puesto, no se que tiene que ver el manual del programador aqui cuando que tiene que ver como se programa a como se hace por debajo.

¿Qué es lo que he dicho que no son partes físicas?
Vuelvelo a leer y me lo citas, porque igual no lo has entendido bien.

naxeras escribió:Lo que quiero decir es que no tiene pinta que se esté emulador microcodigos de ningun SDK si no lo que hay por debajo porque ademas se ven las partes descritas en el link que he puesto.

Pues entonces explícame esto:

EMaDeLoC escribió:De hecho hubo una etapa en la que el juego de Wave Race mostraba el agua como una malla en vez de los polígonos pintados. Bueno, pues lo de dibujar mallas es una función de las librerias oficiales:

Lo podeis ver en la página 91 de este manual oficial en PDF.
Eso significa que se ha cambiado una función del SDK por otra a la hora de ejecutar el juego, algo que no sucedería de implementarse el RSP pues no existe la instrucción "dibuja una malla".

¿No es opensource el core? ¿No puede mirar el código y salir de dudas?

Buenas señores, estoy por comprarme la de10-nano pero me asalta la siguiente duda…. Cuánto tiempo le queda a esta placa fpga hasta q salga la siguiente generación?
Porque la verdad me fastidiaría comprar la de10 y q en 3 meses por ejemplo saliera otra placa fpga más potente q valiera para el mister o el xtreme….. alguien podría infórmame?
Gracias y un saludo amigos.

EMaDeLoC escribió:De hecho hubo una etapa en la que el juego de Wave Race mostraba el agua como una malla en vez de los polígonos pintados. Bueno, pues lo de dibujar mallas es una función de las librerias oficiales:

Lo podeis ver en la página 91 de este manual oficial en PDF.
Eso significa que se ha cambiado una función del SDK por otra a la hora de ejecutar el juego, algo que no sucedería de implementarse el RSP pues no existe la instrucción "dibuja una malla".

Te inventas cosas. Lo que ocurría en Wave Race es que, debido a un error en la aplicación de las texturas, había un espacio entre los bordes que hacía aparecer eso que parecía una malla.
NO se cambió en ningún momento una función por otra porque no se tiene control externo sobre las funciones ejecutadas.
Se explicó perfectamente en su momento. ¿Por qué no dejas de inventarte preocupaciones y entras en Discord y hablas con Robert? Si no sabes inglés, dime lo que quieres que le pregunte y se lo transmito, hablo con él a veces.

No se ha creado un renderizador sintético, es una implementación del RDP en progreso y por ello con algunos errores (cada vez menos).
¿Qué dificultad tiene entender eso?

Elazul escribió:Te inventas cosas.

He mostrado un vídeo donde ocurre, no me lo he inventado.

Elazul escribió:Lo que ocurría en Wave Race es que, debido a un error en la aplicación de las texturas, había un espacio entre los bordes que hacía aparecer eso que parecía una malla.
NO se cambió en ningún momento una función por otra porque no se tiene control externo sobre las funciones ejecutadas.

Bien, gracias, es una explicación factible de lo que ocurre en el vídeo y que se puede confundir con la ejecución de la función dedicada a ello. Aunque llama la atención que solo ocurría en Wave Race, pero será cosa de la malla de agua en concreto.

Siendo así zanjo el tema.

Elazul escribió:Se explicó perfectamente en su momento. ¿Por qué no dejas de inventarte preocupaciones y entras en Discord y hablas con Robert? Si no sabes inglés, dime lo que quieres que le pregunte y se lo transmito, hablo con él a veces.

Te pedí expresamente que pasaras el Discord e hiciste caso omiso:

EMaDeLoC escribió:

Elazul escribió:Si quieres saber más, pregúntale a él, es un tio muy accesible.

Si pasas el enlace al Discord lo agradecería. Supongo que no necesitaré preguntar porque no creo que haya sido el único en expresarle las mismas dudas que las mias.

A ver si ahora serias tan amable de pasarmelo.
Traquilo que de ingles controlo lo suficiente y suena fatal que vayas presuponiendo que no tengo el nivel como para entenderlo, aún cuando tus intenciones sean buenas. Especialmente si he puesto capturas y enlaces de documentación de la N64 en inglés (sin subtitular).
Es offtopic, pero estuve un par de años poniendo subtítulos en unos vídeos como afición y actualmente la mitad de los vídeos que sigo de Youtube están en inglés. Así que tranquilo, no tendré problema.

Elazul escribió:No se ha creado un renderizador sintético, es una implementación del RDP en progreso y por ello con algunos errores (cada vez menos).
¿Qué dificultad tiene entender eso?

Ninguna.
¿Qué dificultad hay en entender que puedo mostrar mis dudas razonadas sobre como se esta implementando el core en base a determinados bugs y glitches relacionados con emuladores?
¿Qué dificultad hay en entender que tenga dudas cuando los juegos programados con el SDK oficial funcionan y los que tienen microcódigos personalizados aún tienen glitches?
¿Exactamente cual es el problema de expresar mis dudas?

No sé, otros compis no me han dado la razón y no voy diciendo que "se inventan cosas" o sugiriendo que tienen alguna dificultad en sus conocimientos como has hecho tú.
Lo digo por mantener el buen rollo, no por nada en especial.

giseisha_famicom escribió:Buenas señores, estoy por comprarme la de10-nano pero me asalta la siguiente duda…. Cuánto tiempo le queda a esta placa fpga hasta q salga la siguiente generación?
Porque la verdad me fastidiaría comprar la de10 y q en 3 meses por ejemplo saliera otra placa fpga más potente q valiera para el mister o el xtreme….. alguien podría infórmame?
Gracias y un saludo amigos.

Tranquilo que le quedan años, y más con la comunidad que tiene, en ese aspecto no es una raspberry.

Lo que le ha pegado un buen mazazo tanto a nuevos usuarios como a desarrolladores es su subida de precio.

Preguntas y respuestas con respecto a la Mars FPGA la "sucesora" de la MiSTer.



A destacar

• Los 700€/$ incluyen la placa, una carcasa para "consolizarla" y los conectores JAMMA.
• La placa soporta Dreamcast y Naomi
• La placa soporta CPS3

Pues visto que salvo Robert que parece que es el único en la actualidad que se está tomando en serio el picar verilog para MiSTer me da que pensar que los de MARS FPGA ya están empezando a secuestrar el desarrollo, no?

A los que entiendan de esto:

¿Sería posible lograr que dos DE10 NANO trabajaran en paralelo y así duplicar las especificaciones o parte de ellas?

DJ Deu escribió:¿Sería posible lograr que dos DE10 NANO trabajaran en paralelo y así duplicar las especificaciones o parte de ellas?

Desde mi humilde opinión, creo que si. Tiene ancho de banda de sobra para comunicarse con otros dispositivos.
Pero sería un complejidad extra, pues habría que pensar un protocolo para comunicar ambas y estructurar la máquina a crear para esa configuración, por ejemplo una placa para CPU y otra para GPU.

¿Para qué sistema estas pensando? Porque para replicar hardware más avanzado de Dreamcast en adelante, creo que sale mejor la emulación en muchos aspectos.

Una pregunta un tanto meh. Tengo entendido que los juegos arcades se van sumando a la lista de juegos en cuanto los “traducen” de las placas originales al míster. Pero ¿es posible acceder a más arcades aunque sea a través de emulación de toda la vida?

Y otra cosa, no se qué hice pero el core de x68000 se me queda colgado al abrirlo. Hay alguna forma de resetear los núcleos o tendré que borrarlo?

EMaDeLoC escribió:

DJ Deu escribió:¿Sería posible lograr que dos DE10 NANO trabajaran en paralelo y así duplicar las especificaciones o parte de ellas?

Desde mi humilde opinión, creo que si. Tiene ancho de banda de sobra para comunicarse con otros dispositivos.
Pero sería un complejidad extra, pues habría que pensar un protocolo para comunicar ambas y estructurar la máquina a crear para esa configuración, por ejemplo una placa para CPU y otra para GPU.

¿Para qué sistema estas pensando? Porque para replicar hardware más avanzado de Dreamcast en adelante, creo que sale mejor la emulación en muchos aspectos.

Bueno, ampliar la vida útil del aparato, porque al final de lo que se trata es más celdas, más sistemas y mejor implementación, no?

Imagino que hasta podría ser factible añadir lectores de cartucho o unidades de disco con esa combinación.

No se, pero yo y el 98% de los usuarios de MiSTer seguro que preferimos comprar otra DE10-Nano y carcasa a desembolsar 700 pavos más IVA y aduanas por la MARS.

Pero me mosquea porque me temo que les van a regalar (si no lo han hecho ya) placas a todos los devs de MiSTer y el desarrollo va a caer en picado, de hecho, ya está sucediendo.

@DJ Deu A ver, por un lado si entra N64, que entra, todo lo que salió antes entraría. Lo que falta es gente y documentación para implementarlo.
Mi comentario por lo de Dreamcast es que a partir de ese sistema todos los que salieron tiene GPUs con cierta estandarización del mercado. Es decir, se basan en APIs ya existententes como Glide, OpenGL, DirectX, etc para generar los gráficos, y las CPU casi 3/4 de lo mismo, se basan en CPUs estandar. No estamos hablando de hardware único y exótico como un RCP de N64 o los chips de vídeo de Saturn, sino de hardware más común derivado del PC.
Que PS2, PS3 y GC también tienen sus particularidades, si, pero hablamos de hardware más complejo de replicar en una FPGA y que además no es tan raro de encontrar, ya que exceptuando GC existen decenas de millones de consolas disponibles.

Lo que quiero decir es que el esfuerzo de replicar hardware más potente que no quepa en una De10 nano es muy grande y tal vez no valga la pena habiendo el original todavía siendo bastante fácil de conseguir.

Otra cosa sería hardware de arcades, pero precisamente desde los 2000 y salvo contadas excepciones, son PCs con alguna gráfica y un software optimizado.

En esos casos el problema es parchear los juegos para que funcionen con otro hardware, pero el hardware original, pues no es tan original.

No digo que no merezcan preservarse, digo que a alguien no le merecería el esfuerzo de replicar la complejidad de hardware tan grande si no tiene una buena motivación detrás y mucho tiempo para dedicarle.

Y actualmente por el dineral que cuesta una De10 nano, por el precio de comprar una para expandir puedes comprar los sistemas originales y sacarles provecho.

Dicho esto, tampoco estaría mal el que se pudiera añadir otra De10 para aumentar las capacidades y ampliar sistemas que no cabrian en una sola.