Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@magno@wwwendigo bueno, lo que está claro es que el más ignorante aquí soy yo, por eso recurro a vosotros emocionado con la ilusión de un niño, y además procuro hacerlo públicamente para que otros también puedan enriquecerse de vuestros aportes. Lamento que mis inquietudes hayan provocado el reavive de un pique personal entre vosotros, así que en adelante para futuros hilos procuraré no formularos la misma cuestión a ambos, ya que hacemos un flaco favor al foro fomentando vuestro hastío. Si aún así ya entonces discrepáis será cosa 100% vuestra.
Volviendo al tema del arbitraje del bus, tras leeros y considerar vuestras estimaciones he ido un paso más allá buscando la opinión de rusty, que es el nick que usa ex-programador de Criterion Games que postea en Sega-16, y que ha trabajado en la Ps2, Xbox, o Dreamcast entre otras máquinas. En relación a este mismo asunto su opinión es la siguiente:
rusty
It's interesting to note that the main issue that made the Saturn difficult to work with, the inability to access memory at the same time from either CPU, was also a major issue on the PS2. The difference was that the PS2 gave the programmer actual mechanisms (Scratchpad, VU local memory, DMA L/S)to get around that issue and stay off the bus during processing, as much as possible.
Otro tipo le dice:
The bus thing is handled automatically though...
rusty
Not really. Yes, cache helps to keep the CPU off the bus (that's the whole idea) but in order to make use of it, you have to constantly stick to the rules of the memory controller and what happens in the events of a cache miss or hit. It's not enough to have cache alone - you need a larger area of memory that is under direct control of the programmer to really help with that.
The more accesses you have to do, the more chance you have of a bus collision and having one of the CPU's stall as it waits for access. That's bad. You don't want that. Programmer friendly scratchpad/locked cache/DMA is how you limit the number of individual accesses, by staying off the bus until you really needed to read/write large chunks of data.
Parece opinar más o menos lo que magno, y rusty no es un fanboy anti SEGA que se lee la Wikipedia para ir de guay por los foros angloparlantes, el tipo tiene credibilidad más que nada porque demostró en su momento que su currículum es real.
Ahora yo, carente de autoridad moral en la materia, planteo; ¿y no podría ser un poco ambas cosas? Me refiero a que si bien por un lado como dice magno poner dos procesadores autosuficientes "en línea" con el mismo pozo de memoria dentro de un hardware tan primitivo como el de Saturn, el cual está semi-arbitrado por un micro-controlador, es de facto un cuello de botella. Y por otro lado, aunque lo anterior sea cierto, tampoco es algo dramático como sostiene wwwendigo, ya que muchos cacharros han funcionado así de siempre.
Qué pesadito eres... te di la oportunidad de dejar tierra por medio en su momento y no dije entonces qué pensaba sobre ti (o sea, la realidad que hay tras una falsa imagen, me empezaron a saltar las alarmas por varias cosas que soltaste en su momento), pero nada, insistes, pues venga, explica al foro algunas cosillas:
1.- Cómo alguien que se chulea de trabajar diseñando FPGAs (sin que nadie te preguntara al respecto, por cierto, tú sacas el tema a relucir cuando te apetece aún sin venir a cuento para fardar, no te creas que no se te nota), y de conocer al dedillo arquitecturas como la de SNES o el 6502, puede llegar a decir que las cpus 6502/65c816 son arquitecturas RISC y empezar un debate de besugos para seguir erre que erre afirmando eso aún cuando se te estaba diciendo que ni de coña (y por tanto, lo lógico y normal es que te la envainaras no vaya a ser que te cazaran, como fue el caso).
Es un DISPARATE mayúsculo y una clara señal de INVENTs en acción. Porque es que nadie diría eso ni en primero de carrera.
2.- Cómo alguien que dice conocer tanto sobre diseños de cpus es capaz de negar la clara referencia y diseño basado en el 6502 para el SPC700 (misma arquitectura de registros, mismos conceptos de tratamiento de memoria, mismas latencias y juego de instrucciones similar, y hasta el mismo comportamiento "anómalo" en algunas operaciones usando como registro genérico auxiliar uno de los de direccionamiento, con el mismo nombre además, mira qué coña de coincidencia, mismo uso de "página cero" etc). Y basarse para afirmar esto en algo tan absurdo como una diferencia en los OPCODEs, que no en las instrucciones en sí (funcionalidad, latencias, etc).
INVENT detected. Cualquiera con dos dedos de frente ve el enorme paralelismo entre ambas cpus, no por nada la mayoría de ensambladores actuales para 6502 soportan al SPC700 y viceversa. A pesar de su incompatibilidad binaria (seguramente forzada por Sony para evitar problemas de licencia y copyright. no querría pagar dos veces por lo mismo y reutilizar así un producto ya usado previamente y reajustado para esta función) y toda la tostada.
3.- Como alguien que dice estar "desarrollando" su propio código para SNES y modificar un juego, código para una traducción de textos (esfuerzo muy loable, ese mérito no se debe quitar), es capaz de decir a la vez que está desarrollando el código él mismo (algoritmo X de descompresión y blabla) y.... a la vez ir desglosando que será en TRES LENGUAJES de programación distintos como mínimo según cada funcionalidad a desarrollar. Y lo que es peor, usar C++ para desarrollar código para la SNES (lógico de cojones, vamos, usar C++ y orientación de objetos y clases y demás para hinchar código y espacio ocupado con él, en una consola de 16 bits con enormes constricciones en cuanto a memoria RAM y ROM). Y además decir que "no me llega el espacio en un cartucho estándar de X Mb"...
Para cualquiera que haya desarrollado un poco queda muy claro qué significa esto:
Copy & paste de código ajeno.
No hay ninguna justificación para creando código "de nuovo" se use, no digo ya C y ensamblador (aceptable, pero no mucho si tienes problemas de espacio, aunque un buen compilador de C y técnicas de programación decentes apenas tienen sobrecoste en espacio o velocidad contra ensamblador), que puede ser razonable, sino C, ensamblador y... C++ para "algunas cosillas".
La única razón es el uso de código ajeno donde ya esté implementada una serie de funcionalidades a usar, código en C++ y que o no encuentras ese código en C/ensamblador o no quieres adaptarlo a C/ensamblador (porque no es lo mismo escribir tu propio código que ponerse a leer el ajeno y tomarlo como base). Pero entonces hay que decirlo, y viendo cómo te gusta fardar.... te vi clarísimo la patita en ese momento.
Y no entiendas mal, no hay problema en la reutilización de código, por ejemplo libre, para este proyecto. Pero sí lo hay en que lo vendieras como si fuera algo que estuvieras implementando tú.
Así que mejor, para ti, es no hacerme referencia, porque sé de qué cojeas, y que no eres/haces lo que por aquí sueltas, tendrás tus méritos reales, no digo que no, pero no sé dónde comienza la realidad y lo ficticio .
Punto y final. Quien quiera ver que se fije un poquito en ciertos detalles.
Obvia, por tanto, mencionarme.
Sexy MotherFucker escribió:@magno@wwwendigo bueno, lo que está claro es que el más ignorante aquí soy yo, por eso recurro a vosotros emocionado con la ilusión de un niño, y además procuro hacerlo públicamente para que otros también puedan enriquecerse de vuestros aportes. Lamento que mis inquietudes hayan provocado el reavive de un pique personal entre vosotros, así que en adelante para futuros hilos procuraré no formularos la misma cuestión a ambos, ya que hacemos un flaco favor al foro fomentando vuestro hastío. Si aún así ya entonces discrepáis será cosa 100% vuestra.
Volviendo al tema del arbitraje del bus, tras leeros y considerar vuestras estimaciones he ido un paso más allá buscando la opinión de rusty, que es el nick que usa ex-programador de Criterion Games que postea en Sega-16, y que ha trabajado en la Ps2, Xbox, o Dreamcast entre otras máquinas. En relación a este mismo asunto su opinión es la siguiente:
rusty
It's interesting to note that the main issue that made the Saturn difficult to work with, the inability to access memory at the same time from either CPU, was also a major issue on the PS2. The difference was that the PS2 gave the programmer actual mechanisms (Scratchpad, VU local memory, DMA L/S)to get around that issue and stay off the bus during processing, as much as possible.
Otro tipo le dice:
The bus thing is handled automatically though...
rusty
Not really. Yes, cache helps to keep the CPU off the bus (that's the whole idea) but in order to make use of it, you have to constantly stick to the rules of the memory controller and what happens in the events of a cache miss or hit. It's not enough to have cache alone - you need a larger area of memory that is under direct control of the programmer to really help with that.
The more accesses you have to do, the more chance you have of a bus collision and having one of the CPU's stall as it waits for access. That's bad. You don't want that. Programmer friendly scratchpad/locked cache/DMA is how you limit the number of individual accesses, by staying off the bus until you really needed to read/write large chunks of data.
Parece opinar más o menos lo que magno, y rusty no es un fanboy anti SEGA que se lee la Wikipedia para ir de guay por los foros angloparlantes, el tipo tiene credibilidad más que nada porque demostró en su momento que su currículum es real.
Ahora yo, carente de autoridad moral en la materia, planteo; ¿y no podría ser un poco ambas cosas? Me refiero a que si bien por un lado como dice magno poner dos procesadores autosuficientes "en línea" con el mismo pozo de memoria dentro de un hardware tan primitivo como el de Saturn, el cual está semi-arbitrado por un micro-controlador, es de facto un cuello de botella. Y por otro lado, aunque lo anterior sea cierto, tampoco es algo dramático como sostiene wwwendigo, ya que muchos cacharros han funcionado así de siempre.
¿O aquí no puede haber medias tintas?
Ahí lo que hay son medias tintas, lee BIEN lo que dice, evidentemente está exponiendo el problema potencial, que existe, pero eso es ignorar también de paso que una cpu con cachés internas se tira más del 90% del tiempo trabajando directamente con ésta, para eso están. Sólo accede a memoria en fallos de caché y lo hace para explicarlo rápido, por "ráfagas" (bloques de caché a actualizar con nuevos datos o código).
Menciona que la PS2 tiene scratchpad, lo cual está muy bien, pero es enormemente reducida en este caso, y la cpu de la PS2 es un auténtico galimatías en sí de distintos cores y unidades funcionales, todas capaces de devorar datos rápidamente. En ese caso el scratchpad es casi una necesidad contra el caso de la Saturn. Además tengo la sospecha de que es necesaria esta memoria para evitar que las VU, por lo menos la VU1, tenga que estar accediendo continuamente a memoria (las cachés que monta el EE son en principio "exclusivas" del 5900, tengo dudas de que todos los VU tengan acceso a éstas, por tanto el scratchpad sería necesario para evitar accesos de éstas, por lo menos VU1 que es la que no se menciona como "estrechamente ligada" a la cpu, como la VU0).
Los SH2 son simples cpus RISC ESCALARES (una instrucción por ciclo de reloj, máximo, no tienen unidades funcionando en paralelo), el 5900 es SUPERESCALAR de dos vías (aunque en orden), lo cual aumenta sus requisitos a memoria en cuanto a transferencias, sin contar a su vez las VU0 y VU1 (y la propia unidad vectorial integrada dentro del 5900), todas estas unidades necesitan una gran cantidad de acceso a datos o a código a ejecutar. El tema es especialmente acuciante por el tema de las muy anchas unidades vectoriales usadas en ese chip (que aumentan la presión sobre el subsistema de memoria, mucho más de lo que podría ser el caso de los SH2 y su diseño más simple).
Pero es que hay más cosas, el BALANCE de ancho de banda y capacidad del EE contra los 2xSH2 de la Saturn ES PEOR, normal que tenga que tener un mayor control tanto de "memoria interna" (fuera del bus a memoria principal) como mecanismos de compensación. Es que no le queda más remedio.
El bus del EE es de sólo 16 bits, otra cosa no mencionada, así que a pesar de funcionar a 400 MHz sale perdiendo respecto al bus de 32 bits y síncrono con el reloj de las cpus de la Saturn, porque se trata de meter en un mismo chip un auténtico infierno de unidades vectoriales de distinto tipo y ralea, una cpu "genérica" superescalar, etc, que lo que hacen es meter claramente una sobrecarga al sistema.
La solución de la Saturn es BÁSICA pero más que suficiente para sus necesidades, es simplemente un "dual core" (maestra y esclava, en realidad) en un mismo chip y con sus cachés L1 exclusivas, "peleando" por acceder a memoria de vez en cuando, pero de la misma forma que hay competencia y de hecho MAYOR en un EE por este recurso. La probabilidad de que haya colisión es relativamente baja, pero aún siendo apreciable lo único que pasará es que se producirá un stall en la cpu esclava hasta que acabe la maestra de acceder a memoria, punto. Todas las cpus sufren stalls bajo ciertas condiciones, ni siquiera son especialmente acuciantes en este caso.
No hay que perder de perspectiva que la Saturn es una consola más simple, la cpu en sí es más simple, escalar y en orden, relativamente predecible su comportamiento aún siendo un 2X1, en cambio el EE.... es un puñetero infierno tal cual está planteada.
Supongo que quien critica en ese foro tanto a la Saturn no se habrá puesto a programar en ésta, porque posiblemente llegaría a la conclusión de que es más fácil, a pesar de la simpleza de la solución de la Saturn para aumentar la potencia, programar para ella que para la PS2. Confunde un problema teórico con la práctica, son cpus muy distintas en cuanto a qué hacen y cómo lo hacen (trabajan) internamente. Esto marca también muy diferentes requisitos a memoria. Es que no sé cómo no tiene en cuenta la complejidad interna y mayores requerimientos que tiene que conocer del EE y sus múltiples unidades/procesadores vectoriales, debería ver esa gran diferencia contra la Saturn.
Realmente hasta el diseño del CELL de la PS3 es más elegante que el del EE de la PS2, así que ojo cuidado por pensarse que está todo "mejor atado" que en otras cpus porque tenga más mecanismos compensatorios que otras soluciones (porque los necesita, entre otras, evidentemente el EE bien usado es una muy potente cpu, pero eso no quiere decir que sea ni fácil ni que no tenga sus problemas). Aunque entiendo que alguien que aprende a controlar el EE puede llegar a desarrollar un gusto un tanto masoca que le lleve hasta a loar sus soluciones a pesar del galimatías que es a primera vista.
PD: Insisto, los ingenieros de SEGA no eran tontos, que la solución sea "precaria" por falta de elegancia no quiere decir que no fuera suficiente o incluso eficiente para ese nivel de potencia. Los primeros sistemas multicore basados en x86, mucho antes de tener sistemas operativos robustos con capacidad de soporte multicore alguno e incluso cpus con unn soporte multiprocesador más serio (a partir de los Pentium), estoy hablando de como mucho Windows 3.1, se basaban en hacer algo muy parecido a lo que hizo SEGA con SATURN;
En el 92 se vendían máquinas basadas en 2X i486 como estaciones de trabajo estando dos cpus colgando del mismo subsistema de memoria y con sistemas operativos que NO soportaban directamente esta configuración y con una compartición del bus basado en el mismo concepto de "maestra-esclava". Hacía falta por tanto usar software que soportara específicamente esta configuración, no había ayudas del s.o. para esto, y aún así se vendían.
Porque ni quien las diseñaba ni quien las usaban eran tontos, era una solución más que suficiente para estaciones de trabajo x86 (las primeras realmente "serias" que intentaban rivalizar con las estaciones basadas en RISC, en realidad, antes de la era Pentium que es la que consiguió poner en igualdad el tema). Si el soft soportaba esta configuración (estaba programado PARA usarla) simplemente volaba, el aumento de rendimiento era más que aceptable en dicho momento, por muchos peros que se le pusiera a nivel técnico.
Esa misma solución con un sistema con más procesadores (como es en realidad el caso del EE, aunque no sean todas cpus genéricas, sí aumentan requisitos a memoria), y capacidades superiores (uso de instrucciones vectoriales, superescalaridad) puede no ser suficiente. No debería comparar ese señor con la PS2 el hard de Saturn, debería tener en cuenta la presión sobre la memoria del EE y cómo de facto el interfaz a memoria es más "estrecho" proporcionalmente también en la PS2.
Sexy MotherFucker escribió:Parece opinar más o menos lo que magno, y rusty no es un fanboy anti SEGA que se lee la Wikipedia para ir de guay por los foros angloparlantes, el tipo tiene credibilidad más que nada porque demostró en su momento que su currículum es real.
Ahora yo, carente de autoridad moral en la materia, planteo; ¿y no podría ser un poco ambas cosas? Me refiero a que si bien por un lado como dice magno poner dos procesadores autosuficientes "en línea" con el mismo pozo de memoria dentro de un hardware tan primitivo como el de Saturn, el cual está semi-arbitrado por un micro-controlador, es de facto un cuello de botella. Y por otro lado, aunque lo anterior sea cierto, tampoco es algo dramático como sostiene wwwendigo, ya que muchos cacharros han funcionado así de siempre.
¿O aquí no puede haber medias tintas?
No todo es blanco y negro, obviamente, pero que lo de poner los dos micros sobre la misma RAM de la forma rudimentaria que está creado fue un gran error y un handicap reconocido tanto por programadores como por los propios ingenieros en su día, que desaconsejaron totalmente hacerlo. En el libro que menciono se habla de que fue una decisión puramente comercial para poner sobre la mesa unos números de procesamiento de polígonos parecidos a los de PS y que no tuvo en cuenta impedimentos técnicos. Lo que has copiado de Rusty es exactamente lo que te comentaba en mi respuesta anterior, que ni tan siquiera una caché L1 mejora las cosas dramáticamente en un escenario como la Saturn. Fíjate en el esquema multi-procesador que puse que la cache L1 (la de 32Kb) es individual de cada micro y la L2 es compartida para agilizar la comunicación entre ambos micros. Nada de eso lo tiene Saturn porque no se pensó para 2 micros en paralelo.
Sexy MotherFucker escribió: Y por otro lado, aunque lo anterior sea cierto, tampoco es algo dramático como sostiene wwwendigo, ya que muchos cacharros han funcionado así de siempre.
Es que eso no es cierto, por mucho que tú le creas: dudo que algún "cacharro" haya funcionado con multiprocesador paralelo accediendo a la misma memoria sin arbitraje como en Saturn. Puede haberlo habido en algún momento de la historia, no digo que no, pero te aseguro que no sólo no es lo común, sino que es exactamente lo que se evita siempre.
Cuando empezaron los paradigmas multi-procesador, lo primero que se resolvió fueron las contiendas de bus: el arbitraje de bus no sólo implica quién tiene acceso al bus, sino además quién tiene la prioridad en caso de colisión, lo que se llama políticas round-robin, prioridad de escritura, de lectura, puerto prioritario, etc, la posibilidad de fraccionar transacciones, encolar peticiones a memoria, etc. Es lo que hace el bus AXI por ejemplo, que cumple la especificación AMBA-4.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@magno@wwwendigo buff, lo primero gracias a ambos, si pudiese os pagaba por opinar (unos cafeses o algo), pero habéis abierto varios frentes que me parecen todavía más interesantes, y que necesito tiempo para asimilar, y proyectar mi siguiente post.
magno cuando puedas sería interesante que expandieses un poco lo que propuse con el 68020 y sus FPUs, ya que si no recuerdo mal tienes experiencia con su ensamblador, o con el del 68030 ya no recuerdo.
Señor Ventura
MegaAdicto!!!
31.324 mensajes desde ene 2014
Editado 1 vez. Última: 10/05/2018 - 23:30:08 por Señor Ventura.
Sexy MotherFucker escribió:@magno@wwwendigo bueno, lo que está claro es que el más ignorante aquí soy yo, por eso recurro a vosotros emocionado con la ilusión de un niño
Un niño feo
Si tu eres ignorante, esto es todo lo que puedo aportar yo
editado: Joder, se están matando entre ellos, y tu aquí en plan "que bonito es todo" xDDDD
Sexy MotherFucker escribió:magno cuando puedas sería interesante que expandieses un poco lo que propuse con el 68020 y sus FPUs, ya que si no recuerdo mal tienes experiencia con su ensamblador, o con el del 68030 ya no recuerdo.
Lo intentaré, pero va a ser difícil porque no tengo mucha idea del SH2 y no tendría elementos para compararlo con 68020+FPU. Y ya sabes que si yo no sé de algo, me callo y que opinen los que saben del tema.
@magno Yo estoy contigo al 100% para lo bueno y para lo malo (te equivocarás como todos...pero poco), espero no perderte del foro. Eres un tipo bastante imparcial, complétamente siempre en estado de calma. Magno no es Seguista, no es Nintendero, simplemente hace lo que le gusta hacer y no entra en bucles infinitos hacia la nada. PD: Si nadie lo hace lo tenía que decir yo.
Lo primero agradeceros a todos los mensajes y estoy estudiando vuestras respuestas, porque seguro que me he equivocado en algunas cosas y no he sido claro en otras.
El emulador es yabause. endrás que descargarlo, ir a Archivo/Configuracion/Bios y meter un enlace a la bios de Saturn (tendrás que buscarla por ahí). Luego ir Archivo/Configuración/Entrada y en la entrada de Mando darle a la llave inglesa. Te saldá un mando de Saturn, vas dándole a los botones y le asignas una tecla del teclado, con eso basta para probar cosas. Yo he puesto los cursores, A S D y Z X C para los botones, Ctrl Izq y Ctrl Dcho para los gatillos y ENTER para Start. Luego cargas un juego y pulsando las teclas del 1 al 6 activas/desactivas el VDP1 y las diferentes capas del VDP2.
Es un emulador impresionante, puedes ir viendo el código que ejecutan los SH-2, incluso meter tú instr en ensamblador. Para ver la memoria del VDP1 te metes en Depurar/VDP1 y te salen.
@magno@wwwendigo Nada de guerras personales aquí por favor, agradezco vuestros comentarios porque se aprende mucho, pero no vale la pena pelearse por estas cosas.
Respecto a Virtua Figther
En el tema en concreto de VF, yo también he leído que la idea es usar un procesador por personaje, pero lamento decir que no me llega primero para saber si realmente es así, y luego hasta que punto se usan los SH-2 para saber cómo van de sobrados.
Para los que no entiendan este ejemplo: Cada SH-2 calcularía los vértices de cada polígono de su luchador. Una vez hemos terminado con ambos se ha de mandar al VDP1 los comandos para dibujar esos polígonos. Si hay que aplicar alguna historia (como iluminación,sombreado,etc), eso ha de incluirse en los comandos mandados al VDP1. Luego hay que ver qué pasa con el fondo y mandar los comandos necesarios al VDP2. Luego habría que ver temas de IA, colisiones entre luchadores, sonido,etc. Y vuelta a empezar.
Por supuesto, si tenemos dos personajes distintos un procesador terminará antes que otro (suponiendo que los 4Kb de la caché les dé). ¿Qué hace ese SH-2 mientras el otro aún está ocupado? Puede esperar (lo cual es un desperdicio) o puede ir haciendo algo, habría que ver cómo y qué podría hacer, porque en ocasiones podría ser un SH-2 y en otras el otro.
Respecto al bus
Cuando dije que el sistema maestro-esclavo era diferente a los actuales lo dije por varias cosas. En primer lugar físicamente los sistemas actuales de andar por casa (PCs, consolas, móviles, tablets,...) suelen ser sistemas multinúcleo dentro del mismo encapsulado. En el caso de Saturn, es un sistema multiprocesador con 2 procesadores separados. Segundo porque los S.O. (tal y como habéis comentado) dan soporte, antes no era así y había que hacer este soporte a mano.
Desde el punto de vista lógico tampoco es que cambie mucho, pero antes todo era mucho más rudimentario que ahora. A eso me refería. Eso no significa que no funcionara claro.
@Sexy_MotherFucker Como te dije, los esquemas no los he sacado de la web que mencionas (que por supuesto he leído). Si no de la documentación original de Sega. Si quieres no aburrirte en las lluviosas tardes de invierno aquí tienes un link: http://antime.kapsi.fi/sega/docs.html
Tienes los esquemas generales de Saturn en el 2do y 3er link.
No lo he mencionado porque no lo veo necesario, pero has insistido en que no me crea lo que leo en sega-16 o en otros foros. Por supuesto, intento documentarme bien antes de hacer un post como éste, yo lo leo todo y luego saco mis conclusiones. He estado hablando con gente de foros de desarrollo también, y hay cosas que no acabo de entender que no he puesto (lamentablemente).
Por cierto, que la parte del DSP-SCU la hice con gusto porque sabía que ansiabas saber si el uso correcto de ese DSP desataría el poder oculto de Saturn. Lamento decirte que, según mis investigaciones, en la práctica, el uso del DSP del SCU daría un pequeño chute pero no es lo que esperabas.
Sexy MotherFucker
Light Sider!
9.307 mensajes desde may 2008 en Evolution baby
Editado 3 veces. Última: 11/05/2018 - 00:51:38 por Sexy MotherFucker.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@danibus gracias por el link, le echaremos un ojo porque creo que esa en concreto no la tengo
Sobre el DSP llevo tiempo investigando yo también por mi cuenta, y lamentablemente llego a las mismas conclusiones que tú, aunque todavía no las he expuesto en ningún otro foro porque me gustaría seguir contrastando información con gente más entendida para ver qué se me escapa; en concreto en este hilo ha salido el tema del nulo arbitraje de los SH2 por parte del controlador de memoria en Saturn, y hay que ver hasta qué punto el DSP sale airoso de ese brete.
¿Que has tocado algún tema pensando en mí dices? Vaya, pues gracias xD, yo realmente agradezco estos hilos. Además que si me conoces de otras comunidades sabrás que ahora mismo ando metido en un zafarrancho de proyecto con la Saturn, y este post me viene de lujo para despejarme pero sin salirme de contexto ; )
En el tema en concreto de VF, yo también he leído que la idea es usar un procesador por personaje, pero lamento decir que no me llega primero para saber si realmente es así, y luego hasta que punto se usan los SH-2 para saber cómo van de sobrados.
Lo que está claro es que de VF a VF2 en AM#2 le cogieron el punto al tandem de los SH-2, ya que al margen de que aprovechasen más inteligentemente el VDP2 para restarle trabajo al VDP1 (suelos), subir de 30 a 60 fps aumentando el número de polígonos por luchador, y con una lógica general más compleja, no es moco de pavo en apenas un año. Coño, es que se notó también del primer Daytona al segundo, y de Panzer Dragoon al Zwei.
Edit: Ojo, que lo de una CPU por personaje son declaraciones contrastables del propio Yu Suzuki, no es ningún mito de internet, ni nada que haya que "averiguar".
precisamente está reconocido por uno de los ingenieros que colaboraron en el libro "The rise and fall of SEGA" que se desaconsejó el poner el otro procesador en paralelo por el motivo que he dicho...
¿Pero dónde lo reconoce, en ese libro, o en alguna otra entrevista? ¿Se puede leer en Internet todo lo inherente al tema que estamos tratando?
En el libro que menciono se habla de que fue una decisión puramente comercial para poner sobre la mesa unos números de procesamiento de polígonos parecidos a los de PS y que no tuvo en cuenta impedimentos técnicos.
Tom Kalinske (ex CEO de SEGA América) dice que a él no le consta que "calzasen" el segundo SH2 por esos motivos, aunque también hay que decir que SEGA Japón fué totalmente hermética y déspota con la filial americana en ese y otros muchos asuntos durante esa época, por lo tanto el hombre lo mismo ni papa de lo que se sucedió en realidad; según dijo en varias entrevistas se pilló un cabreo porque Hideki Sato no le hizo ni puto caso ni a él ni a su equipo en lo referente a sus sugerencias para el diseño de la Saturn.
Sí si, me refiero a que, además de procesar el 3D de los personajes, hay que gestionar otras cosas. IA, los fondos, los marcadores, efectos "especiales" (pocos claro),etc Me gustaría saber si eso lo hace fijo uno de los dos SH-2 (sería lo más normal) o si se le otorga esa faena al SH-2 con personaje más "simple" (al terminar antes).
danibus escribió:Lo primero agradeceros a todos los mensajes y estoy estudiando vuestras respuestas, porque seguro que me he equivocado en algunas cosas y no he sido claro en otras. @magno@wwwendigo Nada de guerras personales aquí por favor, agradezco vuestros comentarios porque se aprende mucho, pero no vale la pena pelearse por estas cosas.
Respecto a Virtua Figther
En el tema en concreto de VF, yo también he leído que la idea es usar un procesador por personaje, pero lamento decir que no me llega primero para saber si realmente es así, y luego hasta que punto se usan los SH-2 para saber cómo van de sobrados.
Para los que no entiendan este ejemplo: Cada SH-2 calcularía los vértices de cada polígono de su luchador. Una vez hemos terminado con ambos se ha de mandar al VDP1 los comandos para dibujar esos polígonos. Si hay que aplicar alguna historia (como iluminación,sombreado,etc), eso ha de incluirse en los comandos mandados al VDP1. Luego hay que ver qué pasa con el fondo y mandar los comandos necesarios al VDP2. Luego habría que ver temas de IA, colisiones entre luchadores, sonido,etc. Y vuelta a empezar.
Por supuesto, si tenemos dos personajes distintos un procesador terminará antes que otro (suponiendo que los 4Kb de la caché les dé). ¿Qué hace ese SH-2 mientras el otro aún está ocupado? Puede esperar (lo cual es un desperdicio) o puede ir haciendo algo, habría que ver cómo y qué podría hacer, porque en ocasiones podría ser un SH-2 y en otras el otro.
Respecto al bus
Cuando dije que el sistema maestro-esclavo era diferente a los actuales lo dije por varias cosas. En primer lugar físicamente los sistemas actuales de andar por casa (PCs, consolas, móviles, tablets,...) suelen ser sistemas multinúcleo dentro del mismo encapsulado. En el caso de Saturn, es un sistema multiprocesador con 2 procesadores separados. Segundo porque los S.O. (tal y como habéis comentado) dan soporte, antes no era así y había que hacer este soporte a mano.
Desde el punto de vista lógico tampoco es que cambie mucho, pero antes todo era mucho más rudimentario que ahora. A eso me refería. Eso no significa que no funcionara claro.
Lo primero decir que yo contestaba directamente a la pregunta de sexymotherfucker (¿está bien puesto?), no a lo que tú hubieras dicho previamente al respecto o incluso el primer post del hilo.
Lo de Virtua Fighter como no se tenga a mano el código original o se desensamble y se deje uno la vista en él, no hay forma de saber si es cierto o no. Pero es lo que se comenta en algunas citas, y además es más que factible y hasta lógico.
En realidad el orden que has puesto de los pasos es "correcto" pero para serlo en el más sentido estricto el primer paso es el último que pones (se actualiza el "estado" del juego primero con actualización de IA y físicas/colisiones, después posiciones de objetos, IOs varias (bueno, que algunas son lo primero que se hace, realmente), y ya actualizado "el estado del mundo" se pasaría al render gráfico, esto es, la imagen se calcula después de actualizar los estados en el juego teniendo en cuenta las inputs, así que es mejor decir que es después lo del cálculo de vértices y renderizado y demás blablas gráficos, pues digamos que es la misma "escena" que la planificada en la actualización de estado del juego la que se calcula, aunque evidentemente al ser un bucle continuo haciendo los mismos pasos también es cierto que "después de renderizar una escena toca actualizar estados, IA, etc", pero eso es para la siguiente imagen). Es sólo para por si alguien tiene dudas que sepa que el tema del renderizado es la última etapa del bucle.
Sobre lo del bus, ya admites que lo de las dies separadas es una diferencia que a nivel lógico no implica mucho, pero es que eso se ha usado en PCs de no hace mucho como algo normal (Pentium D, por ejemplo, o incluso en C2D para formar Quad Cores, si nos ponemos así incluso podríamos hablar de los Ryzen para servidor, incluso, es un clásico de la industria), más diferencia marca la falta de soporte por el s.o. de esas máquinas y la necesidad de hacer todo "a mano" sin ayudas. Pero bueno, también es cierto que el código era "más simple" en cuanto a ser menos masivo, las herramientas también han cambiado mucho por el escalado del desarrollo actual vs el de los 90 (mucha más gente en desarrollo, necesidad imperiosa de uso de lenguajes orientados a objetos, y delimitación de áreas más pequeñas del desarrollo de un engine dado que ahora muchos subsistemas son mucho más complejos que antes, ahora hay más facilidades, pero también es necesario un soporte multihilo muy fino en el soft, p.ej.).
Mi respuesta a SexyMFucker es respecto a que para ese momento, con esas cpus, la solución era más que válida, que evidentemente no quiere decir que no hubiera colisiones ni problemas potenciales de rendimiento no presentes en otras soluciones. Pero era un momento donde era una solución más que válida.
No niego que hubiera ese potencial problema, lo que hago es minusvalorarlo (o no ponerlo en primera plana para hablar de la máquina y sus limitaciones), es distinto. Creo que es importante no exagerar estas cosas porque al final la gente acaba pensando que uno de los SH2 estaba de adorno o no aportaba apenas nada, cuando sí.
Sexy MotherFucker
Light Sider!
9.307 mensajes desde may 2008 en Evolution baby
Editado 1 vez. Última: 11/05/2018 - 01:33:14 por Sexy MotherFucker.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
wwwendigo escribió:Lo primero decir que yo contestaba directamente a la pregunta de sexymotherfucker (¿está bien puesto?)
No, pero lo que menos me preocupa es que escribas mal mi nick xDD.
Cuando pueda te comento una cosa que has dicho en la página anterior, porque no me cuadra.
Lo de Virtua Fighter como no se tenga a mano el código original o se desensamble y se deje uno la vista en él, no hay forma de saber si es cierto o no.
Intentar programar para dos C.P.Us tiene sus problemas.
Virtua Fighter usa una c.p.u diferente para calcular a cada luchador. Las dos CPU empiezan al mismo tiempo, pero hay un tiempo de retraso cuando una tiene que esperar a la otra para "ponerse al día" con la información. Un sólo procesador central de gran velocidad sería preferible. No creo que todos los programadores tengan la habilidad de programar para dos CPUs, la mayoría sólo puede obtener alrededor de una vez y media la velocidad que se obtiene de un sólo SH-2. Creo que sólamente uno entre 100 programadores es suficientemente bueno como para sacar a flote ese tipo de velocidad en Saturn.
Yu Suzuki en una entrevista para Next Gen en 1995. Como verás también comenta lo mismo que tú dices de que en esa época programar un sistema Dual CPU era un jodido infierno para el desarrollador medio.
wwwendigo escribió:Lo primero decir que yo contestaba directamente a la pregunta de sexymotherfucker (¿está bien puesto?)
No, pero lo que menos me preocupa es que escribas mal mi nick xDD.
Cuando pueda te comento una cosa que has dicho en la página anterior, porque no me cuadra.
Lo de Virtua Fighter como no se tenga a mano el código original o se desensamble y se deje uno la vista en él, no hay forma de saber si es cierto o no.
Intentar programar para dos C.P.Us tiene sus problemas.
Virtua Fighter usa una c.p.u diferente para calcular a cada luchador. Las dos CPU empiezan al mismo tiempo, pero hay un tiempo de retraso cuando una tiene que esperar a la otra para "ponerse al día" con la información. Un sólo procesador central de gran velocidad sería preferible. No creo que todos los programadores tengan la habilidad de programar para dos CPUs, la mayoría sólo puede obtener alrededor de una vez y media la velocidad que se obtiene de un sólo SH-2. Creo que sólamente uno entre 100 programadores es suficientemente bueno como para sacar a flote ese tipo de velocidad en Saturn.
Yu Suzuki en una entrevista para Next Gen en 1995. Como verás también comenta lo mismo que tú dices de que en esa época programar un sistema Dual CPU era un jodido infierno para el desarrollador medio.
A ver hostia , que yo digo que la única forma de comprobar las palabras de esa cita es, fuera de creerla (que no hay razón para no hacerlo), está en comprobar el código fuente original.
Y si te refieres al tema que recalcas, es que es una obviedad que es mejor usar una única cpu con el doble de potencia que usar esos 2 SH2 para alcanzar esa misma potencia, pero a lo sumo, muchas veces menos, y ya no te digo cuánto en el caso de desarrollar en C y ensamblador directamente en una consola "pelada" de APIs y soporte para multiproceso fuera de usar una aproximación "Close to the metal". Incluso a día de hoy sería preferible contar con una cpu con la mitad de cores pero con éstos el doble de potentes en básicamente cualquier tipo de soft.
A comienzo de los 90 había muy poco soft multiproceso, menos aún multihilo, sobre todo fuera de servidores o el mundo de las estaciones de trabajo, que ahí eran más punteros y había más tradición de programar sistemas multiprocesador (además de tener ss.oo. mucho más robustos en ese sentido, unix y sabores por ejemplo).
Hasta en el mundo PC era una excepción hasta finales de los 90, y aún así se tardó no poco en usar sistemas multiproceso. En consolas había tradición de usar sistemas con múltiples procesadores para tareas distintas, pero no es lo mismo ya que estos coprocesadores/cpus se encargaban de subsistemas completos muy concretos, no era un tema como el programar el programa-base de forma que se repartieran las tareas entre varias cpus similares.
Hubo que esperar hasta la generación de la PS3 y de la XBOX360 para que esto fuera el pan de cada día, incluso la PS2 tan citada no deja de ser un sistema que sigue las reglas de consolas anteriores (el EE no es un sistema multiprocesador al uso, aunque sí tenga varios coprocesadores integrados).
Me imagino que ya lo conocerás, pero en los "SEGA SATURN TECHNICAL BULLETIN #SOA-8-9-10" se habla del DSP con algún ejemplo de código (en el 8). La pena es que en el número 10 hablan de un "ejemplo" de programa completo, pero ni idea de si se podrá descargar de algún lado. Copio-Pego desde el SS TBulletin SOA-10 lo que hace el ejemplo y lo que gana en rendimiento:
The DSP sample program performs 3D point transformation, i.e. it multiplies a 4x3 homogeneous matrix by an arbitrary list of 3-element vectors (the fourth element of each vector is presumed to be 1). The program attempts to take full advantage of the parallelism built into the DSP, and the transformation matrix, the input points, and the output points are transferred using the SCU’s DMA capability. The sample code performs point transformations roughly a third faster than the equivalent code written in SH2 assembly language, even allowing for the time spent transferring data into and out of the DSP’s memory.
Sexy MotherFucker escribió:¿Pero dónde lo reconoce, en ese libro, o en alguna otra entrevista? ¿Se puede leer en Internet todo lo inherente al tema que estamos tratando?
Pues no sé si se puede leer por internet, pero el libro "The rise and fall of SEGA" para mí es una maravilla, me lo leí casi de un tirón porque estaba muy enganchado. Además hablan de una cosa curiosísima: cómo Virtua Fighter paradójicamente llevó a Sony a orientar su Playstation a una plataforma 3D en vez de la plataforma 2D que heredó del SNES-CD.
Sexy MotherFucker escribió:Tom Kalinske (ex CEO de SEGA América) dice que a él no le consta que "calzasen" el segundo SH2 por esos motivos, aunque también hay que decir que SEGA Japón fué totalmente hermética y déspota con la filial americana en ese y otros muchos asuntos durante esa época, por lo tanto el hombre lo mismo ni papa de lo que se sucedió en realidad; según dijo en varias entrevistas se pilló un cabreo porque Hideki Sato no le hizo ni puto caso ni a él ni a su equipo en lo referente a sus sugerencias para el diseño de la Saturn.
Pues en el libro hay una cita de Kalinske que dice lo contrario. Capítulo 6:
"The Japanese are making the decisions for the U.S. market," Kalinske later grumbled, "and they do not know what they are doing."
Refiriéndose a la decisión precipitada de los japoneses de poner 2 procesadores. A mitad de ese capítulo se habla del procesamiento paralelo y la locura para desarrolladores que fue, con entrevistas a algunos desarrolladores que hablaron del tema. En otro capítulo, si no recuerdo mal, se habla de la presentación en el CES o E3 de ambas consolas y cómo la presentación de la PS precipitó el cambio a doble procesador de SEGA. La pena es que mi lector epub del PC no te da el número de página sino el porcentaje que llevas leído; esta información que te comento está en el 41%
Andrómeda escribió:@magno Yo estoy contigo al 100% para lo bueno y para lo malo (te equivocarás como todos...pero poco), espero no perderte del foro. Eres un tipo bastante imparcial, complétamente siempre en estado de calma. Magno no es Seguista, no es Nintendero, simplemente hace lo que le gusta hacer y no entra en bucles infinitos hacia la nada. PD: Si nadie lo hace lo tenía que decir yo.
Muchas veces se subestima lo importante (importantísimo) que es cómo de fácil es programar para un hardware. No importa lo potente que pueda ser un hardware si luego no hay nadie en el mundo que tenga los conocimientos necesarios para sacarle partido.
Aparte, no es sólo cuestión de tener el conocimiento, es que si en un sistema P implementar una tarea x es sencillo mientras que en otro sistema S tienes que partirte los cuernos para hacer lo mismo, obviamente nadie va a querer picar para S.
No entiendo cómo Sega, que no eran precisamente unos don nadie, decidieron tirar por la computación paralela. En los 90 la carrera del hardware aún estaba en mejorar el rendimiento por procesador, aún había bastante margen de mejora. El paralelismo estaba aún en pañales. Se dice que Sony les pilló por sorpresa y por eso doblaron capacidad de proceso doblando CPU, pero no sé qué grado de veracidad puede tener eso si ya 32X tiraba de doble CPU. Con un hardware así tan importante o más que el propio hardware era ofrecer un sdk que simplificase el balanceo de tareas, sincronización, acceso a recursos compartidos y demás. Quizás pensaron que iban a ser capaces de hacerlo y al final resultó más difícil de lo que pensaban.
Sexy MotherFucker
Light Sider!
9.307 mensajes desde may 2008 en Evolution baby
Editado 2 veces. Última: 11/05/2018 - 10:39:09 por Sexy MotherFucker.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@magno no, si lo que dice en la entrevista que yo digo no es que a él le pareciese normal o bien que implementasen el SH2 extra, sino que él supiese esa decisión no fué motivo porque le viesen las oreias al lobo con Sony y fuesen deprisa y corriendo a "incrustar" otro procesador con un martillo. Como se ha expuesto en este hilo SEGA América apostaba por un 68020 debido a lo extendida que estaba ya la programación en los Motorola, y por supuesto al bajo coste de estos en 1994, pero al margen de los rifi-rafes entre SEGA Japón y la filial americana denostando cualquier sugerencia desde occidente, las buenas relaciones con Hitachi imagino que fueron lo que terminó por decantar la balanza para la inclusión de los SH2 en la Saturn. Según se especula en el hilo de Sega 16 que enlacé antes, al parecer SEGA e Hitachi co-diseñaron el SH2, o cuando menos Hitachi mantuvo muchas conversaciones con ingenieros de SEGA durante su diseño cara a su posible futuro uso en la nueva consola de 32 bits, no sé si en el libro "Auge y Caída de SEGA" dicen algo al respecto de eso.
@utreraman gracias por el aviso, ¿existe alguna edición en castellano?
Sexy MotherFucker escribió:@magno no, si lo que dice en la entrevista que yo digo no es que a él le pareciese normal o bien que implementasen el SH2 extra, sino que él supiese esa decisión no fué motivo porque le viesen las oreias al lobo con Sony y fuesen deprisa y corriendo a "incrustar" otro procesador con un martillo. Como se ha expuesto en este hilo SEGA América apostaba por un 68020 debido a lo extendida que estaba ya la programación en los Motorola, y por supuesto al bajo coste de estos en 1994, pero al margen de los rifi-rafes entre SEGA Japón y la filial americana denostando cualquier sugerencia desde occidente, las buenas relaciones con Hitachi imagino que fueron lo que terminó por decantar la balanza para la inclusión de los SH2 en la Saturn. Según se especula en el hilo de Sega 16 que enlacé antes, al parecer SEGA e Hitachi co-diseñaron el SH2, o cuando menos Hitachi mantuvo muchas conversaciones con ingenieros de SEGA durante su diseño cara a su posible futuro uso en la nueva consola de 32 bits, no sé si en el libro "Auge y Caída de SEGA" dicen algo al respecto de eso.
@utreraman gracias por el aviso, ¿existe alguna edición en castellano?
Yo lo he leido en inglés, pero si mal no recuerdo en breve Game press lo va a publicar en castellano.
matasiete escribió:Muchas veces se subestima lo importante (importantísimo) que es cómo de fácil es programar para un hardware. No importa lo potente que pueda ser un hardware si luego no hay nadie en el mundo que tenga los conocimientos necesarios para sacarle partido.
Aparte, no es sólo cuestión de tener el conocimiento, es que si en un sistema P implementar una tarea x es sencillo mientras que en otro sistema S tienes que partirte los cuernos para hacer lo mismo, obviamente nadie va a querer picar para S.
No entiendo cómo Sega, que no eran precisamente unos don nadie, decidieron tirar por la computación paralela. En los 90 la carrera del hardware aún estaba en mejorar el rendimiento por procesador, aún había bastante margen de mejora. El paralelismo estaba aún en pañales. Se dice que Sony les pilló por sorpresa y por eso doblaron capacidad de proceso doblando CPU, pero no sé qué grado de veracidad puede tener eso si ya 32X tiraba de doble CPU. Con un hardware así tan importante o más que el propio hardware era ofrecer un sdk que simplificase el balanceo de tareas, sincronización, acceso a recursos compartidos y demás. Quizás pensaron que iban a ser capaces de hacerlo y al final resultó más difícil de lo que pensaban.
Totalmente de acuerdo, el hardware es muy importante si le sabes sacar el provecho programando correctamente.
La diferencia entre los dos procesadores de Saturn y los de 32X es que en esta última el proceso era asimétrico (dos CPUs diferentes) y además una es maestra de la otra; además las tareas que cada una tenía que hacer ya venían impuestas por la arquitectura del hardware. Pero sí, viendo el extra de complicación que trae meter dos micros en paralelo, deberían de haberle dado una vuelta al tema,
Sexy MotherFucker escribió:@magno no, si lo que dice en la entrevista que yo digo no es que a él le pareciese normal o bien que implementasen el SH2 extra, sino que él supiese esa decisión no fué motivo porque le viesen las oreias al lobo con Sony y fuesen deprisa y corriendo a "incrustar" otro procesador con un martillo. Como se ha expuesto en este hilo SEGA América apostaba por un 68020 debido a lo extendida que estaba ya la programación en los Motorola, y por supuesto al bajo coste de estos en 1994, pero al margen de los rifi-rafes entre SEGA Japón y la filial americana denostando cualquier sugerencia desde occidente, las buenas relaciones con Hitachi imagino que fueron lo que terminó por decantar la balanza para la inclusión de los SH2 en la Saturn. Según se especula en el hilo de Sega 16 que enlacé antes, al parecer SEGA e Hitachi co-diseñaron el SH2, o cuando menos Hitachi mantuvo muchas conversaciones con ingenieros de SEGA durante su diseño cara a su posible futuro uso en la nueva consola de 32 bits, no sé si en el libro "Auge y Caída de SEGA" dicen algo al respecto de eso.
No lo recuerdo que lo comentaran, pero sí se dice que en un primer momento se quería poner un NEC V60, aunque no recuerdo si comentan el por qué de cambiar de micro a los dos Hitachi.
Por cierto, se me olvidó poner el quote del libro de lo que ya se ha dicho sobre Yu Suzuki:
The following quote by Sega's own Yu Suzuki first appeared in NextGen (Next Generation) magazine. “Trying to program for two CPUs has its problems. Virtua Fighter uses a different CPU for calculating each character. The two CPUs start at the same time but there's a delay when one has to wait for the other to catch up. One very fast central processor would be preferable. I don't think that all programmers have the ability to program two CPUs - most can only get about one-and-a-half times the speed you can get from one SH-2. I think that only one out of 100 programmers are good enough to get that kind of speed out of the Saturn.”
Aquí es la primera referencia de una voz de peso en SEGA que estaba en contra de los dos procesadores en paralelo.
ziu
MegaAdicto!!!
3.216 mensajes desde mar 2003
Editado 2 veces. Última: 11/05/2018 - 11:31:58 por ziu.
Hola! Una pregunta, que fue antes la Saturn en Consola o la Arcade Titan-V?
He visto en las Wikis que se lanzaron las dos en el 94, pero me gustaria saber si el diseño principal se hizo pensando en el arcade o la Saturn
¿que diferencias tecnicas hay entre las dos?
¿No creeis que si le hubieran puesto memoria tipo buffer/cache en los dos procesadores SH2(como el VD1) hubiera sido mas facil programar en ellos ?
Ya se que hubieran encarecido mas la consola, pero hubiera ganado mucho en rendimiento, otra opción que veo es que quizás hubieran tenido que eliminar el motorola 68000 y el SH1 y que un SH2 hubiera echo las funciones de estos con un canal de memoria independiente. (Lei por hay que el motorola no podía descomprimir audio y tenia que trabajar con los wav sin comprimir, la PSX le ganaba de calle en este sentido por que tenia mucha mas memoria disponible en audio.)
Que hace exactamente el SH1 a 16mhz?
Gracias!
ewin
MegaAdicto!!!
3.110 mensajes desde nov 2016 en Midgard
Editado 1 vez. Última: 11/05/2018 - 11:29:39 por ewin.
@danibus Lo dije un par de páginas atrás y lo reitero ahora, un gran post lleno de información útil, bien explicada y, además, (cuanto más dulce, mejor), han acudido más personas a redondearlo con sus aportes.
Espero que, junto al hilo del panzer dragoon saga y unos cuantos mas que, de vez en cuando, van surgiendo en este subforo, podamos dar un poco de luz, dignidad y prestigio a una consola mayoritariamente menospreciada. Con sus luces y sus sombras.
Me estoy leyendo el libro en ingles (The Fall..) e impresiona la de cosas que iban pasando por detrás en bambalinas. Muchas veces en internet surge una información y , a falta de fuente, se debe dejar en cuarentena. Me gusta ver como hay personas que van acumulando bibliografia para, por lo menos, debatir con conocimiento de causa.
Un gran hilo, si señor.
pd: comprad saturn japos que estan baratisimas y son un consolón!
@ziu si lees el hilo completo verás que todo eso queda ampliamente explicado.
Sexy MotherFucker escribió:@magno no, si lo que dice en la entrevista que yo digo no es que a él le pareciese normal o bien que implementasen el SH2 extra, sino que él supiese esa decisión no fué motivo porque le viesen las oreias al lobo con Sony y fuesen deprisa y corriendo a "incrustar" otro procesador con un martillo. Como se ha expuesto en este hilo SEGA América apostaba por un 68020 debido a lo extendida que estaba ya la programación en los Motorola, y por supuesto al bajo coste de estos en 1994, pero al margen de los rifi-rafes entre SEGA Japón y la filial americana denostando cualquier sugerencia desde occidente, las buenas relaciones con Hitachi imagino que fueron lo que terminó por decantar la balanza para la inclusión de los SH2 en la Saturn. Según se especula en el hilo de Sega 16 que enlacé antes, al parecer SEGA e Hitachi co-diseñaron el SH2, o cuando menos Hitachi mantuvo muchas conversaciones con ingenieros de SEGA durante su diseño cara a su posible futuro uso en la nueva consola de 32 bits, no sé si en el libro "Auge y Caída de SEGA" dicen algo al respecto de eso.
@utreraman gracias por el aviso, ¿existe alguna edición en castellano?
Pues menos mal que no le hicieron caso a los de SEGA américa.
Un 68020 es una cpu netamente inferior en potencia respecto a los SH2. De hecho estaría en ese punto mucho más desfasada la consola que en su momento la Genesis usando el 68000 (que ya estaba viejo pero seguía vigente en el mercado en su lanzamiento, aunque muy superado).
Sí, el ecosistema de desarrollo era mucho mejor, pero eso no compensa en absoluto las ya evidentes carencias de la línea 680x0 respecto a potencia, en ese momento (sería preferible, de integrar alguno, ir directamente a por un 68040, pero claro, NO era barato, y tampoco una maravilla, vamos, pero por lo menos ahí había margen de frecuencias de funcionamiento e IPC mejorado, más cercano al típico de los RISC más simples disponibles en el mercado). El 68020 estaría bien justo para una consola lanzada a principios de los 90, con sólo unos pocos años de diferencia a la hornada de la propia Genesis (un medio salto de generación, ofreciendo algo más que las 16 bits pero sin lanzarse directamente a lo que significó la "generación de 32 bits" (que es una forma mala de etiquetarla), que en realidad supuso la incorporación masiva de cpus de tipo RISC y un salto de potencia de cpu enorme). Pero no en las fechas de la Saturn o la PS2 (muy buenos copros tendría que tener).
Ojo, hablo de comparar un solo SH2 contra el 68020, no dos, donde la ventaja crece. La única disculpa para SEGA américa sería que el diseño completo de su "consola sugerida" incluyera una serie de coprocesadores mejor balanceados que el producto final, para que tuviera pleno sentido el uso de una cpu más lenta que la versión japonesa.
ewin escribió:@danibus Lo dije un par de páginas atrás y lo reitero ahora, un gran post lleno de información útil, bien explicada y, además, (cuanto más dulce, mejor), han acudido más personas a redondearlo con sus aportes.
Espero que, junto al hilo del panzer dragoon saga y unos cuantos mas que, de vez en cuando, van surgiendo en este subforo, podamos dar un poco de luz, dignidad y prestigio a una consola mayoritariamente menospreciada. Con sus luces y sus sombras.
Me estoy leyendo el libro en ingles (The Fall..) e impresiona la de cosas que iban pasando por detrás en bambalinas. Muchas veces en internet surge una información y , a falta de fuente, se debe dejar en cuarentena. Me gusta ver como hay personas que van acumulando bibliografia para, por lo menos, debatir con conocimiento de causa.
Un gran hilo, si señor.
pd: comprad saturn japos que estan baratisimas y son un consolón!
@ziu si lees el hilo completo verás que todo eso queda ampliamente explicado.
ok, mil gracias, iré mirando el hilo te dejo esta reflexión para ver que opinas si hubieran aprovechado mejor la consola abaratando costes :
"quizás hubieran tenido que eliminar el motorola 68000(no podia trabajar con audio comprimido) y el SH1 y que un SH2 hubiera echo las funciones de estos con un canal de memoria independiente"
Es que el cerebro humano funciona de forma concurrente, no paralela.
Aparte, no todos los problemas/algoritmos pueden sacarle partido, ahí la ley de Amdahl.
Implementar un problema con paralelismo vs concurrencia: 1. Que el problema lo permita. En el caso extremo hay algoritmos donde no se puede paralelizar nada. Esto es así sí o sí, da igual lo listo que sea el programador o lo bueno que sea el sdk. 2. Identificar tareas que se pueden ejecutar en paralelo y asignarlas a cpus. Esto puede hacerlo el sdk (o la plataforma, o lo que sea) o el desarrollador. 3. Gestionar todo lo demás que implica paralelismo si no lo hace el SO (comunicación entre procesos, etc).
Programar en paralelo teniendo que gestionar todo de forma manual es un dolor. La parte de paralelismo en sistemas de computación y la comunicación entre-procesos es de lo más difícil de la carrera de informática (o era hace 20 años).
No sé cómo funciona hoy en día el paralelismo en sistemas en tiempo real, pero me la juego a que son las plataformas las que hacen maravillas. Los programadores de hoy no son mejores que los de hace 20 años, simplemente tienen mejores herramientas.
Sexy MotherFucker
Light Sider!
9.307 mensajes desde may 2008 en Evolution baby
Editado 1 vez. Última: 11/05/2018 - 12:23:55 por Sexy MotherFucker.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@wwwendigo os lo planteé por curiosidad páginas atrás, obviamente de haber optado por el 68020 hubiesen necesitado una FPU anexa para comerse un colín en juegos poligonales, concretamente las compatibles que yo vi son las M68881/82 compatibles también con el 68030:
Pues dime, en tu opinión con un 68020 a 33 mhz (máximo clock según wikipedia), calzando una FPU de esas; ¿Cómo crees que hubiese andado en rendimiento en comparación al combo de los SH2?
Sexy MotherFucker escribió:@wwwendigo os lo planteé por curiosidad páginas atrás, obviamente de haber optado por el 68020 hubiesen necesitado una FPU anexa para comerse un colín en juegos poligonales, concretamente las compatibles que yo vi son las M68881/82 compatibles también con el 68030:
Pues dime, en tu opinión con un 68020 a 33 mhz (máximo clock según wikipedia), calzando una FPU de esas; ¿Cómo crees que hubiese andado en rendimiento en comparación al combo de los SH2?
Que no lo veo. Añadir la coma flotante extra es un sobrecoste importante (además de ser en este caso una solución subóptima, si ya va en la propia cpu vale, pero como chip aparte tendría más sentido una unidad de coma flotante que procese sólo fp32 pero que sea más rápida para los cálculos 3D).
Más bien tendría sentido el 28020 pelado y hacer la T&L en la propia GPU como alternativa y por tanto evitar como la peste los cálculos que no sean en enteros en el 28020. Aún así, la cpu es relativamente débil.
Que sí, que para el momento está bien (el momento del 68020, que ya había pasado) y lo demás, pero es que coño, los SH2 te incluían hasta operaciones MAC, que siempre vienen bien. Además que juraría que los SH2 no tenían tampoco FPU, supongo que se limitarían a usar aritmética de punto fijo y en ese caso el 68020 también podría usarla.
Pero vamos.... es una cpu muy justita para el momento. Más viendo lo que venía. Mejor los SH2.
Sexy MotherFucker
Light Sider!
9.307 mensajes desde may 2008 en Evolution baby
Editado 2 veces. Última: 11/05/2018 - 12:50:46 por Sexy MotherFucker.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@wwwendigo es que si nos paramos a pensarlo el R3000 que monta la primera PlayStation tampoco era precisamente para tirar cohetes en 1994, sin embargo al añadirle el co-procesador matemático se convirtió en un cabroncete bastante eficiente para la geometría, siempre dentro de un contexto de baja potencia. ¿Le pega un repaso taaaan grande a un 68020 + la M8882 @33 mhz? Porque lo que vimos de Saturn en el 80% de los casos fué a los SH2 malamente utilizados, y para muchos fué suficiente en la época.
Sexy MotherFucker escribió:@wwwendigo es que si nos paramos a pensarlo el R3000 que monta la primera PlayStation tampoco era precisamente para tirar cohetes en 1994, sin embargo al añadirle el co-procesador matemático se convirtió en un cabroncete bastante eficiente para la geometría, siempre dentro de un contexto de baja potencia. ¿Le pega un repaso taaaan grande a un 68020 + la M8882 @33 mhz? Porque lo que vimos de Saturn en el 80% de los casos fué a los SH2 malamente utilizados, y para muchos fué suficiente en la época.
Lo que pides es bastante difícil de hacer... Puedes hacer cábalas y pensar más o menos si 68020+FPU es mejor que dos SH2, pero para saberlo hay que hacerse las cuentas. Habría que comprobar cuánto tarda en ejecutarse las operaciones en coma flotantes usadas para el cálculo de la perspectiva (vectores normales de cada superficie), de los vértices, de la cámara... y esos cálculos serían teóricos, sin tener en cuenta el acceso a los datos de las superficies, personajes, input del mando para controlar la cámara... Y eso requiere conocer bien tanto la FPU como el 68020, y saber bien qué calculos 3D se han de hacer por cada polígono.
Sólo hay que ver un poco el esquema de la consola para saber que fue un engendro que Sega montó a toda hostia con la cagalera que le metió Sony con su Playstation. Muy difícil de programar en todos los aspectos lo cual hizo que las empresas fueran dándole de lado poco a poco hasta que se hundió totalmente. Una pena, porque yo disfruté mucho con Sega Rally, Virtua Fighter 2 o Panzer Dragon, pero la cosas como son
Respecto al hilo un trabajo impresionante, igual que los datos que aportan los demás foreros. Disfruto como una vaca leyendo este tipo de hilos
Sexy MotherFucker escribió:@wwwendigo es que si nos paramos a pensarlo el R3000 que monta la primera PlayStation tampoco era precisamente para tirar cohetes en 1994, sin embargo al añadirle el co-procesador matemático se convirtió en un cabroncete bastante eficiente para la geometría, siempre dentro de un contexto de baja potencia. ¿Le pega un repaso taaaan grande a un 68020 + la M8882 @33 mhz? Porque lo que vimos de Saturn en el 80% de los casos fué a los SH2 malamente utilizados, y para muchos fué suficiente en la época.
Pero para qué usar el 68020+copro si sale mucho más barato usar no ya un SH2, sino seguramente los dos. Además que estás contando que se use con la frecuencia máximo, que ya no es moco de pavo y pocas veces se ha visto a esta cpu en ese sabor.
En ese momento había mucha diferencia entre cpus RISC y CISC porque se estaba en un punto donde con la misma cantidad de transistores una cpu RISC hacía maravillas comparativas, y se permitía lujazos como tener cachés L1 nutridas, pipelines con X etapas, y un IPC teórico cercano a 1 contra cpus que ofrecían una fracción de esto.
Con el tiempo esta ventaja se neutralizó, y no sólo porque los CISC empezaron a ser cpus RISC-mixtas, sino porque es en la época donde se integraban entre unas decenas de miles hasta cientos de miles de transistores por cpu donde ésto marcaba la diferencia. Después ya en eras donde se iban integrando millones de transistores esta ventaja se fue neutralizando (y con arquitecturas mucho más complejas).
El R3000 es una cpu bastante decente. De hecho yo estaría más cómodo con ella que con un SH2 (igual porque es más conocida, no digo que no), otro asunto es que teóricamente 2 sH2 ofrecen más en conjunto. Pero en realidad al final el debate sobre estas consolas tiene que ver con otras partes de su arquitectura más que con la cpu principal.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
wwwendigo escribió:Pero en realidad al final el debate sobre estas consolas tiene que ver con otras partes de su arquitectura más que con la cpu principal.
Lo sé, los programadores/ingenieros siempre acabáis recalcando ese punto ante las flipadas de la peña, simplemente que al estar hablando de consolas con pretensiones "geométricas" de la época me parece coherente elucubrar sobre su "fuente" para los cálculos de transformación, normalmente asentadas en las CPUs -cuando no eran ellas mismas- en los hardwares de aquellos años.
Pues bueno, me doy por satisfecho, una paja mental menos, y un poco más de perspectiva sobre el asunto.
wwwendigo escribió:Pero en realidad al final el debate sobre estas consolas tiene que ver con otras partes de su arquitectura más que con la cpu principal.
Lo sé, los programadores/ingenieros siempre acabáis recalcando ese punto ante las flipadas de la peña, simplemente que al estar hablando de consolas con pretensiones "geométricas" de la época me parece coherente elucubrar sobre su "fuente" para los cálculos de transformación, normalmente asentadas en las CPUs -cuando no eran ellas mismas- en los hardwares de aquellos años.
Pues bueno, me doy por satisfecho, una paja mental menos, y un poco más de perspectiva sobre el asunto.
Gracias señor.
Pero mira que eres "perri"...
Es cierto que sí tenían ciertas pretensiones en ese sentido, posiblemente arrastrado todo el tema de la era de juegos poligonales anteriores, donde se tiraba de cpu sobre todo para lograrlo (dado que los coprocesadores de sprites o incluso los blitters nada o apenas nada aportaban, que era como solían afrontar el tema gráfico hasta el momento por lo menos habitualmente).
Pero bueno... ya faltaba poco para empezar a desplazar más y más etapas del tema de la pipeline 3D a las gpus (aún no conocidas como tales). Que si el setup de triángulos al principio, que si todo el T&L después.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
wwwendigo escribió:Pero mira que eres "perri"...
A ver, ayer te quería consultar que de dónde cujons te sacaste lo de que el Emotion Engine tiene algún bus de 16 bits (¿te refieres al acceder a las VU?), porque a mi entender tanto el externo como el interno son de 64 bits. Y para que veas que soy la polla con cebolla, esto en mi emoción se lo escribo a un ingeniero sin ni siquiera consultarlo en Google, espero que no seas muy duro conmigo, hablo de memoria (supongo)
Y que viva la Saturn joder, que está bien conocer sus tripas (a mí me encanta, no creo que tenga que demostrar nada al respecto), pero al final lo que nos vamos a llevar a la tumba son sus PUTOS JUEGOS.
A ver, ayer te quería consultar que de dónde cujons te sacaste lo de que el Emotion Engine tiene algún bus de 16 bits (¿te refieres al acceder a las VU?), porque a mi entender tanto el externo como el interno son de 64 bits. Y para que veas que soy la polla con cebolla, esto en mi emoción se lo escribo a un ingeniero sin ni siquiera consultarlo en Google, espero que no seas muy duro conmigo, hablo de memoria (supongo)
Y que viva la Saturn joder, que está bien conocer sus tripas (a mí me encanta, no creo que tenga que demostrar nada al respecto), pero al final lo que nos vamos a llevar a la tumba son sus PUTOS JUEGOS.
¿Qué ingeniero, qué vas haciendo por ahí por favor?
Nada, es error mío, hablaba de memoria y recordaba que se usaba memoria de tipo Rambus y ésa suele ir en canales de 16 bits (bastante manía le tenía y aún tengo tanto a la empresa como al tipo de memoria).
He hecho una consulta rápida por Google a ver qué fallaba y... cómo está el patio. Toda una aventura.
https://es.wikipedia.org/wiki/Emotion_E ... e_Sony_1-1 (Aquí simplemente dice "128 bits" como bus, sin decir más, cuando hablas de una cpu normalmente siempre se entiende que es el externo, tiro de la madeja de la nota para ver de dónde sacan eso):
¡¡Quieto parado!! Eso es el bus interno y no el que hay para memoria (de hecho hablan del tipo de memoria pero no del bus en sí). Empezamos bien si miramos la wiki española (que no pone por ningún lado el bus a memoria pero sí el interno y sin señalar que es eso, induciendo errores). Curiosamente SI está bien en la wiki sobre la PS2, no en la del EE.
Miro en los lins para la nota de Sony y Arstechnica, que era un sitio muy serio y válido para temas de arquitectura (mucho más antes), y me encuentro que ya no están (mierda, han chapado la "arspaedia"). Pero mirando la página en inglés de la wiki la cosa queda algo mejor aclarada (pero está tanto bien como mal):
Aquí ya dice que usa dos canales de 16 bits a la DRDRAM (lo cual ya me cuadra con los resultados de ancho de banda), no uno, pero si miras el esquema que ponen del EE a su vez, que se ha visto en tantas búsquedas x internet:
Ahí simplemente pone que usa un interfaz de 16 bits contra memoria, nada más (y a 400 MHz y toda la tostada). Muestra "dos flechas" pero no se induce en absoluto que sean dos canales, dado que cada una va en sentido contrario (si hubiera usado un par de dobles flechas, aún colaría, lo correcto sería usar dos dobles flechas y un 2X16bits al lado).
Qué bonito es internet.
Así que sí, aunque no puedo estar seguro del todo, dado que hablaba de memoria y recordando que la RDRAM solía ir en canales de 16 bits, y posiblemente viendo en su momento datos como éste tan "claros", de ahí recordaría que había un solo canal y no dos, como parece que es (y tiene más sentido).
De todas formas, dada la complejidad del EE y sus tareas mucho más bestiales que el dúo de los SH2, con esa capacidad de machacar datos con sus unidades vectoriales y su mayor nivel de integrados colgando del mismo chip, necesita pero seguro tanto o más la velocidad que puede dar ese bus. Aunque claro, ahora ya menos, que va mejor servido de ancho de banda.
Seguramente si busco más encuentro un manual del EE en sí de Sony y ahí se podría certificar al 100% la información, pero dado que medio encaja con lo que pensaba lo de 2x16b, me quedo con esta opción como la más probable (con diferencia, claro, por eso la tomo, si hubiera más duda entre varias habría que investigar más).
Por ejemplo, aquí lo pone como Dios manda (el bus):
Mucho más clara en el tema de los buses (aunque totalmente minimalista, por otro lado). Y sin embargo la caga en el tema de la capacidad de la RAM, ya que pone MBytes donde son Mbits. Pues menos mal que es un "paper" donde te enseñan a programar la PS2 (sí, entiendo que es una errata en ese diagrama en sí, no conceptual ni en el texto del paper, pero... coño, que es un artículo de investigación, pon los datos bien). También es verdad que parece un paper sobre la consola y su cpu de antes de su lanzamiento, pero coño... lo de la RAM va a ser que ni en sueños en ese momento (8x la capacidad final).
Los procesadores de 32X y Saturn son iguales, a menos frecuencia en 32X.
Sí, lo sé, pero tengo una duda; ¿el datasheet que linkas en el primer post es del SH2? Al descargarlo, he visto en la primera página que pone SH7604 Hardware manual, y es diferente al PDF que tenía del SH2 de la 32X. ¿Es el mismo chip el SH2 y el SH7604? Mi confusión es mayor porque dentro de ese documento del SH7604 hace referencia a otro documento llamado "SH-1/SH-2 programming manual".
Por lo demás, he podido terminar por fin de leer todo el post y es absolutamente grandioso, muy bien explicado. Se me ha quedado pendiente una curiosidad... ¿hay información acerca de los comandos que se envían a los VDP para dibujar las escenas? ¿Son metadatos, escrituras en registros, código máquina...?
Y por último, una fe de erratas; creo que donde dices
Esa ram es del tipo SRAM. Este tipo de RAM es muy rápida si hacemos muchas lecturas seguidas, o muchas escrituras. Pero si combinamos ambas, el rendimiento cae en picado.
Realmente te estás refiriendo a memoria SDRAM; la SRAM es Static RAM, que no necesita refresco, mientras que la SDRAM (Synchronous Dynamic RAM) va síncrona al reloj y necesita refresco periódico para mantener la información; además, la SDRAM funciona mediante comandos y como dices, es muy rápida haciendo lecturas o escrituras en burst, y penaliza algo combinar lecturas y escrituras: tras hacer un comando RAS, la fila abierta puede usarse para leer o escribir enviando sucesivos comandos CAS (ahorrando por tanto el comando RAS y el tiempo RAS-to-CAS), aunque efectivamente, no puedes combinar en un mismo burst una lectura y una escritura.
@magno Por lo que yo tengo entendido SH-2 = SH7604 Hardware manual y programming manual son dos documentos distintos claro, pero del mismo chip. Si pones link a lo que tienes lo miro.
danibus escribió:@magno Por lo que yo tengo entendido SH-2 = SH7604 Hardware manual y programming manual son dos documentos distintos claro, pero del mismo chip. Si pones link a lo que tienes lo miro.
Pues yo tenía el que pusiste en el hilo del 32X, que es un datasheet cuyo título es: "Hitachi Vehicle Operating System for SH-2, Communication Manual". Ése pensaba que era el Programming Manual del SH-2, pero parece que no. El que has linkado en el hilo de Saturn es el Hardware Manual.
¡Excelentísimo post! ¡Muchísimas gracias por compartirlo con nosotros! Te lo has currado, está muy bien redactado y ya me gustaría que revistas y webs especializadas hicieran semejantes labores de investigación.
Solo un apunte: la última captura de transparencias en juegos 3D no es del Dead or Alive, es del Battle Arena Toshinden, uno de los primeros juegos de lucha en 3D en llegar a nuestras consolas y compatibles.
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
(no veo el momento de jugar al Virtua Hydlide!!!!!!) 
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
, que yo digo que la única forma de comprobar las palabras de esa cita es, fuera de creerla (que no hay razón para no hacerlo), está en comprobar el código fuente original.
![[triston]](/images/smilies/nuevos/triste_ani2.gif "tristón")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
Toda una aventura.![[tadoramo]](/images/smilies/adora.gif "Adorando")
