wwwendigo escribió:Pues entonces NO seamos canelos (es broma
) y léete las especificaciones del Altera usado y párate en la parte que habla sobre IP Blocks de uso genérico (donde sí, se tiran de varias bloques genéricos, menciona explícitamente multiplicadores y otros para funciones de DSP, y no, yo no recordaba los FPGA siendo así de "completos" ni con tanto extra), que es una de las cosas que más te venden en ese FPGA y que no hace referencia precisamente al slice que es la parte básica que entendemos como FPGA (y que lo primero que miré es cuantos elementos básicos o celdas que decía poder simular, y no parecen suficientes). Evidentemente quieren que te ahorres implementar bloques como los mencionados en el slice, cuanto menos. Y me da que los necesitarían para este caso.
¿Quieres que me vuelva a leer las especificaciones de la Cyclone V otra vez? No me esclavices que ya lo hago todos los días en el curro
Es difícil que puedas seguir el ritmo de evolución de las FPGAs si no trabajas con ellas porque van a un ritmo espectacular. Yo estoy puesto al día con las UltraScale de Xilinx, pero no son la última generación tampoco, esto da vértigo.
Y no confundas lo de los IPs... Xilinx, Altera y Lattice, los fabricantes de FPGAs principales, siempre te proporcionan IPs o cores para que aceleres parte de tu diseño: FIFOs, BRAM, multiplicadores, DPLLs, filtros FIR, FFT/IFFT, etc... Y algunos de esos cores son de DMAs, por ejemplo. Pero esos DMAs no tienen nada que ver con los de una Super Nintendo, ni ninguno de los cores que tengan a su disposición con las applicaciones de Altera tienen que ver. Simplemente son atajos para hacer funciones más básicas.
wwwendigo escribió:Y sí, le llamo "emulador" porque no está intentando simular LOS CIRCUITOS de los chips, que es lo que te estoy diciendo y ellos afirman que están recreando al 100% los chips originaes, SIMULA su comportamiento, esto es, ellos se han creado un circuito propio y distinto que recrea lo que ellos piensan que es el bloque de X chip que hace. Que es EXACTAMENTE lo mismo que hacen los emuladores, sólo que en vez de implementarlo en un circuito lógico lo implementan en código soft.
Que ya no hacen los FPGA como se recuerdan (y sí, lo de los bloques de IPs extra para "ayudar" en el FPGA no es algo que yo me esperara de mis recuerdos de cómo funcionaban los FPGAs, que yo recordaba como slices puros y duros, pero así están las cosas hoy en día, por lo que parece, lo que tengo claro es que sin tener las IPs originales no puedes recrear fidedignamente su funcionamiento, se pongan como se pongan).
Puedes llamarle "emulación", pero no lo es; nadie en el mundo profesional usa ese término para referirse a una "implementación". Igual que acabas de usar la palabra "simular" y tampoco es el mismo concepto que se usa en este mundo: simular es contrastar el funcionamiento lógico esperado de la lógica de una FPGA sin llegar a la implementación, haciéndolo a través de una aplicación y no en la propia FPGA.
Y de nuevo insisto: sin tener las IPs originales puedes hacer una implementación que funcione igual que el original, puesto que si las entradas y salidas coinciden en tiempo y funcionalidad, el diseño es equivalente y no está emulado, está implementado de otra forma.
Fíjate lo absurdo que es si compraras un circuito 74LS139 (el decoder de toda la vida) a Hitachi y luego te quejas a Motorola porque el suyo no está implementado igual... Hitachi y Motorola hacían 75LS139 cada uno a su manera, por dentro los transistores eran diferentes y estaban diferentes, y durante 30 años nadie ha insinuado que uno estuviera "emulando" al otro. Simplemente eran diferentes implementaciones del mismo circuito, como en este caso.
wwwendigo escribió:Lo del HDMI por supuesto pasa igual en un PC, aunque fuera la señal por VGA, pero por la forma en que funciona el mismo, la única forma de solventarlo sería con hard dedicado a enviar señal analógica y un soporte directo del mismo con un driver, no usando la pipeline gráfica del sistema.
Pero son los de Analogue los que están presumiendo de zero lag, y eso no es posible contra la SNES cuando meten buffers por medio que se tienen que activar, sí o sí (por lo menos si la emulación es medio precisa como dicen), su funcionamiento cuando llega una señal de vsync (y entonces el sistema emulado, insisto, NO se usan las IPs originales para programar el FPGA, es cuando empezará a hacer lo que se supone que hace una SNEs y... el sistema tendrá que interceptar los scanlines y recrear la pantalla para crear una salida para el HDMI, en el ... siguiente vsync).
Cuando digo DOS bufferes no me refiero a que implementen doble buffer, que también (en la opción full buffered de la Super NT), sino a que dado que se reescala la salida a 1080p y se hace además aplicación de filtros de algún tipo (seleccionables y seguramente algunos que no pero activos por defecto), se necesitan dos buffers:
1.- El original a 256x224 de resolución, que es donde se guardaría la salida de la SNES.
2.- El buffer final reescalado desde el previo, a 1920x1080, y donde se aplicarían además los filtrados activos.
Aclaro que la SNES no usa ningún buffer, todo se hace al vuelo cuando llega el vsync, y en ese mismo vsync.
Puede que el tiempo en crear el segundo buffer sea mínimo, hasta puede que se pueda "anular" su peso si se hace muy rápido y en el "largo" tiempo que hay entre vsync y vsync, pero está ahí, y nada quita el problema de un buffer mínimo y la espera al siguiente vsync. Con la opción full buffered de esta consola se agrega aún más lag, hasta ellos lo reconocen. Y de hecho tienen una opción más rápida que parece que simplemente no respecta el vsync y envía el buffer que se está renderizando cuando llega la señal de vsync (supongo que haciendo el reescalado y filtrado al vuelo en ese momento, pero a tiempo). ¿Había tearing con la SNES? No, con esta opción sí. Incluso por defecto parece que podría haberlo.
¿En PC pasa lo mismo? No lo he negado, niego la mayor de Analogue al afirmar que es zero lag mientras en el mismo material de prensa dicen que los emuladores están cargados de lag. No señor, eso dependerá del PC y la potencia disponible, que por mucho que tengan que compensar otros temas, no dejan de usar cpus bastante más rápidas ahí sea un PC decente. Amén de que en PC puedes usar Vsync variable o una pantalla a muchos más Hz que 60 (aunque esto podría dar problemas en caso de usar vsync para sincronización del juego, aunque eso depende de cómo controle el tema el emulador usado, si simula o no los 60 Hz para el sistema y usa refrescos más altos simplemente para minimizar el lag, poder se puede hacer, pero como no tengo pantalla de 120 Hz por aquí disponible, pues no es algo que haya comprobado).
Claro, es lo que te comentaba antes: la SNES no usa ningún buffer extra, solo la VRAM para generar "al vuelo" la imagen. Pero como bien explicas, lo mismo pasa en un PC; o también en cualquier re-escalador que pongas a la salida de una SNES, y sin embargo, sigues jugando a la SNES real. El lag por salir a mayor resolución es inevitable, lo es también en SNES9x o Higan, pero eso no tiene nada que ver con la implementación de la SNES de Analogue.
Lo del Zero Lag, si has seguido el desarrollo, se refieren al core de la SNES, no a los "extras" que quedarían fuera de la consola real. Pero es un término muy comercial y lo usan, puesto que sí me creo que la parte que implementa a la SNES, desde la entrada del mando a la salida de RF, tenga el mismo lag que tenía la SNES original.
Lo que venga tras esa señal de video, también lo tendrás agregando resamplers de video a la SNES real.
wwwendigo escribió:También niego la otra mayor de Analogue, ellos han dicho varias veces que los chips están perfectamente replicados en el FPGA, es que te están diciendo que son exactamente iguales, evidentemente no a nivel de transistor por lo que dices, pero dan a entender que tienen la misma funcionalidad al dedo, que cada unidad funcional está implementada a nivel de circuito, vaya.
Es que sí tienen la misma funcionalidad, no entiendo de dónde sacas que no. Y sí, cada unidad funcional está a nivel de circuito lógico, en slices, CLBs, DPS48, PLLs o lo que sea que lleve la FPGA que necesiten para hacer la misma tarea que en la SNES. No hay ninguna mentira en lo que dicen.
wwwendigo escribió:Y deberías saber que sin los esquemas de esos chips eso no lo pueden asegurar, que su solución es la ingeniería inversa típica que también usan los emuladores, excepto que realmente hayan destapado los chips y con microscopio los hayan analizado y sacado el diseño de cada circuito dentro de cada chip de la SNES original. Y de paso se hayan pasado por el forro de los xxx las IP (aquí por lo que significa literalmente, no para hablar de ningún bloque ni ASIC sino de la propiedad intelectual) de nintendo, sony, etc.
Qué manía con las IPs... De verdad que estás confundiendo términos... Pero vamos, que el esquema del 65C816 lo tenemos todos los que nos interesa un poco la electrónica y replicarlo al 100% es muy sencillo.
Replicar el SPC-700 es sencillo también porque está bien documentado y el DSP de audio también.
Lo que es más oscuro es la PPU, y se tiene suficiente información de qué salida da la PPU cuando cambia cada entrada como para poder hacer una implementación 100% idéntica en cuanto inputs/outputs.
Por cierto, que eso se hace a nivel profesional todos los días: cuando hay algún producto en el mercado que hace algo que el tuyo no, analizas cómo varían las salidas en función de los cambios en la entrada, y te ingenias un algoritmo que haga lo mismo. Eso no infringe ninguna patente porque es la implementación lo que se patenta, y la mía será 100% seguro diferente a la otra, pero 100% compatible.
wwwendigo escribió:Que va a ser que no. Así que no es lo que pretenden, ni cero lag (de hecho no pueden asegurar que tenga menos lag que un PC potente, ¡puede que sea al revés!), ni están implementando los chips originales de la SNES en el FPGA porque simplemente no pueden excepto que se quieran comer un paquete en los juzgados (amén de que por lo que ponía en la ficha de Altera veo difícil que el slice tenga suficientes elementos para todos los chips de la SNES, mencionaba algo así como 100.000 elementos básicos, muy justo, de todas formas casi seguro necesitarían usar algunas de las funcionalidades como DSPs que ya incorpora el FPGA).
¿10000 elementos básicos muy justos? ¿¿cuántos años hace que no usas una FPGA, macho?? Si te digo lo que hago yo todos los días de estos últimos 15 años con 24000 slices FLIPARÍAS en colores. Transmisores de TV digital completos en 19000, un micrcontrolador en 500, un microprocesador completo en 1500...
Y tampoco hay que darle más vueltas al asunto... si tú quieres creer que está "emulando" la SNES, créelo, pero ya te he comentado lo que conocemos todo el mundo por emulación, nada que ver con lo que tiene la SuperNT en sus entrañas. Eres libre de creer lo que quieras
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
