› Foros › Retro y descatalogado › Consolas clásicas
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
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?
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.
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.
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).
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?
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.
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).
AxelStone escribió:@ALCAMJI Muy buen video y sin entrar en guerras absurdas.
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.
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.
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.
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
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.
Elazul escribió:La implementación del RSP está en desarrollo, por eso ves esos errores en el WDC.
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.
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.
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.
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.
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.
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.
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.
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.
EMaDeLoC escribió:No sé cual era el objetivo del comentario, pero no aporta nada.
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.
naxeras escribió:No, el primer emulador HLE transformaba las instrucciones del SDK a GLIDE, en Mister a que las transformas?
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.
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.
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.
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.
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".
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".
Elazul escribió:Te inventas cosas.
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.
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.
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.
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?
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.
DJ Deu escribió:¿Sería posible lograr que dos DE10 NANO trabajaran en paralelo y así duplicar las especificaciones o parte de ellas?
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.