hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Stratoslava escribió: [Ver mensaje]

hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Yo justo lo que no me creo es eso que comentas y que tantas veces hemos hablado por aquí. No creo que el hardware de Saturn no pudiese ser optimizado. Creo que a la consola la faltó tiempo de desarrollo (aprendizaje del modelo RISC + arquitectura paralela) y herramientas de desarrollo mejores (SGL+ y que estuviese disponible para Third Partys), pero no tengo ninguna duda de que en una hipotética Saturn con 6 años de vida (en vez de 2/3) y con unas ventas totales similares a las de Mega Drive los resultados tanto en 2D como en 3D no fuesen mucho mejores de lo que vimos (ojo, que ya fue bastante).

Nextmare escribió: [Ver mensaje]

Stratoslava escribió: [Ver mensaje]

hace relativamente poco, Ben Heck sacó un video en youtube, donde desarma una Saturn y hace un conteo de todos los procesadores y... memoria que tiene disponible la consola... Resulta que la Saturn, señores, tiene 4,2 megabytes de ram, superando incluso a la Nintendo 64 en ese apartado...


sin embargo están horriblemente distribuidos en fragmentos que dejan pocas puertas abiertas a cualquier tipo de optimización. Una lástima... y sobre todo, un desperdicio de recursos

Yo justo lo que no me creo es eso que comentas y que tantas veces hemos hablado por aquí. No creo que el hardware de Saturn no pudiese ser optimizado. Creo que a la consola la faltó tiempo de desarrollo (aprendizaje del modelo RISC + arquitectura paralela) y herramientas de desarrollo mejores (SGL+ y que estuviese disponible para Third Partys), pero no tengo ninguna duda de que en una hipotética Saturn con 6 años de vida (en vez de 2/3) y con unas ventas totales similares a las de Mega Drive los resultados tanto en 2D como en 3D no fuesen mucho mejores de lo que vimos (ojo, que ya fue bastante).

Dicho mal y pronto:

Supongamos que transitamos en una autopista que se hizo con muchas luces, señalizaciones, autoservicios, puestos de comidas rápidas... pero como el mandato se acababa en poco tiempo, el presidente de turno dijo "muchachos, sale como sale" y la bellísima autopista, llena de cosas muy útiles... acabó teniendo un solo carril... encima de todo, muy angosto.

Con nuestro coche gama média, en los años '90, la pista siempre parece está super congestionada y avanzamos a una velocidad promedio de 60km/h.


Año 2020: la autopista sigue siendo la misma, pero le buscaron la vuelta para intentar mejorar la circulación... pero la estructura sigue siendo la misma. Los autos son más veloces y seguros... pero como la autopista sigue teniendo un solo carril, sigue teniendo los mismos problemas que hacía 30 años atras, sólo que ahora los autos marchan a 75km/h

Analogías... ¡cómo no amarlas!

Finalmente me he decidido a traducir la información más interesante de la url que pasé anteriormente (http://cowboyprogramming.com/2010/0...he-sega-saturn/) del blog de Mick West (desarrollador de Skeleton Warriors en la compañia Neversoft) y después comentaré mis impresiones al respecto.

Cowboy Programming escribió: 

1995 Programación en Sega Saturn por Mick West

Este es un documento que escribí en 1995, mientras trabajaba en el primer juego de Neversoft: Skeleton Warriors. Fue el primer juego en el que trabajé y no utilicé el juego de instrucciones de Motorola 68K.
La foto me muestra en el trabajo alrededor de ese momento. El kit de desarrollo de Saturn (la "Caja pequeña" y el ICE) está a la derecha.

El hardware de desarrollo
La máquina de destino es Sega Saturn, que tiene dos microprocesadores SH2 Risc y un 68000. Actualmente solo usamos el Master SH2, el esclavo SH2 se usará cuando descubramos cómo hacerlo. El 68000 se usa para controlar el chip de sonido, no deberíamos escribir ningún código ya que utilizaremos la biblioteca de sonido suministrada por Sega.

El programa está escrito casi en su totalidad en C. Usamos el compilador GNU SH2 para producir la salida del conjunto SH2. Hay algunos módulos SH2, la mayoría limitados a datos puros. Aún no he escrito nada significativo en SH2.

El sistema de desarrollo que usamos es PsyQ. Este no es el sistema de desarrollo estándar de Sega, sin embargo, se considera que es el mejor para todos los que lo han probado. El sistema alternativo es SNASM, por Cross Products, que es propiedad de Sega. La mayor parte del código de muestra proporcionado por Sega está destinado a ejecutarse en el sistema de desarrollo SNASM, sin embargo, es fácilmente convertible a PsyQ.

El sistema PsyQ consiste en una placa de interfaz SCSI que instalas en el PC, un cartucho que se conecta a la Saturn, y un cable para conectar a los dos. El código fuente se compila en el PC y se descarga a Saturn donde se ejecuta. El código se puede depurar desde el PC.

El enlace está controlado por un programa TSR (PSYBIOS) que maneja las comunicaciones entre las máquinas. También permite que Saturn cargue archivos desde el PC de la misma forma que los cargaría desde el CD. Usamos esta característica para cargar los archivos para cada nivel.

Mick también tiene un par de cajas grandes y ruidosas en su habitación. Él también tiene dos PC. El más pequeño de los dos es un E7000PC, que es un Emulador de Circuito Inicial SH2, útil para indicar dónde ha fallado el programa si el depurador PsyQ no lo detiene. También es útil para ver las escrituras de memoria, pero todavía no lo he usado.

La segunda de las cajas ruidosas es lo que se conoce como "caja pequeña" (la "caja grande" original era aproximadamente del mismo tamaño que una nevera pequeña). Esto es esencialmente una Saturn, con interfaces adicionales para el E7000 y para el emulador de CD. También tiene interruptores en la parte delantera para cambiar la identificación del país y para cambiar entre PAL y NTSC.

El emulador de CD es lo que la otra computadora tiene dentro. Un tablero grande que utiliza el disco duro de la computadora para pretender ser una unidad de CD. Puedes construir una imagen de CD en esto y emular en modo de tiempo real para ver cómo se verá el juego cuando llegue al CD. Esto parece funcionar casi en cierta medida, aunque hay algunos problemas con los que estoy trabajando con Sega para tratar de resolverlos.

Me resulta especialmente interesante este relato de Mick West, por tratarse de un programador occidental trabajando en 1995, en el texto habla del día a día en el desarrollo para Saturn y, como podréis comprobar a continuación, programar era casi una odisea.



Lo primero que quiero resaltar es que Skeleton Warriors es un juego de Acción en 2D, que probablemente sería ostensiblemente mas sencillo de programar que los juegos 3D que podrían llevar al límite técnico al sistema (que son los que queremos tratar en este hilo). La fecha de lanzamiento de Skeleton Warriors según Sega Retro fue abril de 1996 en USA y septiembre de 1996 en Europa, el juego no fue lanzado en Japón. Nótese que el juego salió a la venta ya bien avanzado el periodo de vida de la consola.

El desarrollador pone de manifiesto la dificultad para adaptarse a trabajar con SH2 (arquitectura RISC), cuando anteriormente siempre había estado trabajando con Motorola 68K (arquitectura CISC) (Mega Drive llevaba uno de estos, entre muchos otros sistemas). Si la adaptación de 68K a SH2 no tiene que ser sencilla, no me quiero ni imaginar lo que sería para los programadores pasar a trabajar con dos SH2 en paralelo, al menos durante los primeros años.

Básicamente viene a decir que el juego está siendo desarrollado completamente en C y que únicamente está utilizando uno de los procesadores SH2. Y aquí quiero incidir, no está utilizando el SH2 esclavo porque ¡¡¡no sabe cómo hacerlo!!!, es decir, no habla de un problema de arquitectura del sistema, ni de un problema de rendimiento, si de problemas de sincronización de los SH2, si de falta de capacidad de los buses de datos, todo es mucho más básico, tenía problemas para hacer funcionar el código en paralelo, probablemente porque en la documentación de desarrollo de la que disponía no venia bien detallado.

Otro de los aspectos que se tratan en el texto es la información al respecto de los equipos de desarrollo. Este suele ser un tema bastante desconocido para los aficionados, a nivel personal, tengo la suerte de tener un amigo que trabajó de betatester para Sega América y me ha explicado más menos cual fue la situación con Saturn, lo que me permite entrar un poco en detalle sobre lo que habla Mick West en el texto:

Cuando Mick West habla de “small box” se refiere al dev kit Saturn Sophia:



Comenta dos cosas negativas que ya me había dicho mi amigo tester:

1º - Se trataba de un sistema bastante ruidoso (mucho) que hacia que trabajar con él fuese un suplicio.
2º - El sistema producía “crashes” con cierta frecuencia.

Añado un tercer punto que no lo comenta Mick West pero que sí me comentó mi amigo:

3º - Saturn Sophia era un sistema bastante caro de adquirir para realizar el trabajo, sin entrar en cifras, costaba tres veces más que el devkit necesario para programa/testear en PSX.

Este kit de desarrollo se tuvo que utilizar hasta mediados de 1995, que salió el segundo kit de desarrollo oficial de Saturn: Saturn CartDev (https://segaretro.org/Saturn_CartDev). Nótese que en Sega Retro comentan que incluso la primera versión de este segundo kit de desarrollo no era muy confiable, sin embargo, es con este kit de desarrollo donde los estudios comienzan a sacar todo el potencial de la arquitectura paralela de Saturn.



Sí, lo habéis adivinado, los que tenían Saturn Sophia y querían actualizarse al Saturn CartDev tenían que pasar por caja y pagar un coste bastante alto del sistema. Lo que nos lleva al siguiente Dev Kit: Sega Saturn PSY-Q dev kit, que es el que utilizaba Mick y el que utilizó Psygnosis para realizar sus ports a Saturn (http://www.psygnosis.org/history/SATURNPSYQ/), luego los resultados eran los que eran.

NOTA: Si no me equivoco, este es el kit de desarrollo que me enseñó nuestro admin, Ryo Suzuki, en una de las primeras ediciones de Retro Barcelona.

También habla el artículo del Hitachi E7000P, y por lo que comenta Mick, se trata de un accesorio que se podía conectar al Sophia y al PSY-Q.



EN CONCLUSIÓN: El articulo nos muestra que el panorama para un desarrollador externo a Sega en Saturn era absolutamente complicado, así salieron los ports que salieron, que daban la sensación de que Saturn era mucho menos capaz que Playstation y creo toda esta situación debemos tenerla en cuenta a la hora de analizar el “Potencial Teórico VS Realidad”, porque la visión sencilla es la de pensar que la arquitectura hardware de Saturn está mal diseñada, pero eso no está nada claro, de hecho, mi percepción personal como alguien que está cursando la ingeniería informática, es que el diseño de la arquitectura de Saturn es bastante bueno y que los principales problemas de Saturn fueron otros.

Muy, pero que muy buen aporte Nextmare. Voy a estar unos días sin poder postear mucho, así que no puedo ahora mismo explayarme a gusto.

No estoy de acuerdo en una cosa que ya debatiremos, pero de hecho en tu propio post se está ejemplificando que la Saturn tiene un serio problema de diseño en un punto concreto, al margen de que también influyesen otros factores para que a los programadores ajenos a SEGA les costase pillarle el tranquillo.

Cuando pueda entro en detalles  

____________

El diseño de Saturn tiene el problema del acceso a bus. Punto. Las arquitecturas multi core de hoy en día hacen auténticas virguerías para evitar este tipo de problemas.

Yo soy ingeniero informático y profesionalmente estoy especializado en temas de monitorización de sistemas (entre otras cosas que no vienen al caso). Me peleo a diario con sistemas enormes multi-CPU. En grandes empresas no es raro ver sistemas de 32 CPUs, por ejemplo. Los sistemas multi-CPU tienen muchísimas ventajas, es evidente, pero hay algunas normas que aplican y que muchas veces llevan a problemas. Por ejemplo, aún hoy en día, el código de un único ejecutable se diseña normalmente para ejecutar en una única CPU. Eso significa que puedes tener un problema de rendimiento en un proceso que haga que una CPU se ponga al 100% y el proceso no responda o lo haga muy lentamente, y sin embargo el sistema como tal puede estar, como se dice, tocándose los pies. El resto de CPUs pueden estar prácticamente ociosas. Para evitar este tipo de problemas se dividen los procesos en distintos hilos de ejecución (multi-thread) o directamente en procesos diferenciados que tengan distintas funciones y luego interactúen entre sí de distintas maneras. De hecho, a veces se piden varias CPUs no por un tema de rendimiento, sino para garantizar que en caso de problemas de rendimiento el proceso se coma una CPU y no tire el sistema al completo. Este tipo de división en varios hilos a día de hoy NO la hace el sistema operativo. Es algo que se hace al programar, a nivel de diseño del proceso. Y ya os digo que muchas veces no se hace. Estamos hablando de 2018, cuando llevamos décadas con arquitecturas multi-CPU y las herramientas están más que pulidas. Os sorprendería la cantidad de aplicaciones profesionales que valen un dineral que NO están preparadas para multi-thread. Y eso que hoy en día los buses no son un problema (al menos en sistemas profesionales) y la memoria... tampoco a poco que la empresa quiera tener las cosas en condiciones.

Así que puedo imaginarme que, en 1995, sin apenas documentación, sin experiencia en sistemas con varias CPUs, programar para la arquitectura de Saturn de forma eficiente debía ser extremadamente difícil. Es fácil echarle la culpa a los kits de desarrollo de Sega, pero muy probablemente la propia Sega no tenía ni idea de cómo sacar provecho a sus dos CPUs, sobre todo teniendo en cuenta que ambos procesadores no podían acceder a memoria a la vez por su evidente problema de acceso a los buses. Claro que los programadores hubieran deseado tener documentación detallada sobre cómo sacar el potencial a la consola... pero es que dudo que nadie, ni en la propia Sega, supiera cómo hacerlo. Ya os digo que a día de hoy muchas de las aplicaciones profesionales se siguen realizando con un único hilo, y sólo aprovechan varias CPUs porque realmente suelen componerse de varios procesos funcionando a la vez (y el SO reparte los procesos por las CPUs como considera oportuno). Y eso que en los sistemas actuales cada CPU tiene su propio acceso a memoria...

No coincido contigo en muchas de las cosas que comentas Jasvi y no veo relevante comparar una arquitectura paralela como la de Saturn, la cual requiere ser optimizada al máximo, pues todo el software que se desarrolle va a funcionar sobre unas características hardware cerradas, con aplicaciones para servidores multiprocesador empresariales, las cuales no requieren ser optimizadas para una máquina concreta, deben funcionar lo mejor posible en diferentes arquitecturas multiprocesador y además, en muchas ocasiones, son ejecutadas en esas máquinas junto a otras aplicaciones que también consumen recursos.

Ojo, que tampoco estoy de acuerdo con Jroca en algunas de las cosas que comenta en su blog, como que los procesadores SH2 no puedan trabajar en paralelo “El mayor handicap del doble Hitachi SH2 es que compartían bus directo hacía el SCU/DMA y por lo tanto no podían trabajar en paralelo, por lo que cuando los datos no se encontraban en la cache por lo que un procesador acababa por limitar al otro a la hora de procesar.“ o con lo que comenta  de la conversión de código de triángulos a cuadrados “Esta particularidad no era muy bien vista por los desarrolladores que veían como todo el motor 3D que tenían desarrollado para otras consolas tenía que ser re-pensado en el caso de Saturn, así como los modelados de personajes en 3D y demás.” ¿Qué hubiera pasado si Saturn hubiera vendido más que PSX de inicio y las conversiones hubieran tenido que ser de quads a triángulos? Hoy vemos los polígonos triangulares como un estándar, pero en 1994 ese estándar estaba por definir.

Pero, sobre todo, pongo en duda vuestras afirmaciones sobre el bus que conecta RAM como ambos SH2 por cosas como esta que comenta Yu Suzuki, que yo no soy capaz de poner en duda: “En AM2 usamos C para las primeras etapas, y ensamblador después de eso. Conseguimos mantener las CPUs gemelas corriendo a una velocidad 1.8 veces mayor que la velocidad en un sólo chip, eso habría sido imposible usando sólo C.”. Y que serían IMPOSIBLES con limitaciones como las que comentáis. Hagan ustedes la cuenta, si una CPU SH2 corre a 28.6MHz, entonces 28.6 X 1.8 = 51.48MHz, eso o Yu Sukuzi miente…

Pero ya os digo, que no se trata de tener o no razón, simplemente pongo en duda cosas que no veo claras y os animo a seguir buscando información, videos de uso del HW en emuladores o referencias bibliográficas de gente contrastada para seguir enriqueciendo este hilo, que me encanta lo que trata.

Pues fíjate, yo estoy de acuerdo con todo lo que dices y también mantengo todo lo escrito en mi correo... No veo que me contradigas en nada realmente.

Claro que Saturn (1994) no es comparable en global con un servidor corporativo de 2018. Por muchísimos motivos. Lo que estoy diciendo es que en 1994 las arquitectura multi-cpu eran algo bastante novedoso. Es una época en la que los sistemas operativos multiproceso eran la novedad (aunque los Mac los tenían hacía mucho). El avance desde entonces es enorme en ese sentido. Tanto a nivel de hardware como de software. No veas qué virguerías de pipelines multithreads que llevan los sistemas actuales... Saturn sin embargo no da ningún tipo de facilidades ni a nivel de hardware ni a nivel de software. Y lo que decía es que aún hoy, con las arquitecturas ultra-evolucionadas y varias décadas de experiencia sigue sin sacarse todo el partido teórico de las arquitecturas multi-cpu. Hoy en día no importa porque las máquinas tienen potencia para derrochar, y no importa tanto extraer toda la capacidad teórica, pero en 1994, en un sistema cerrado, sí. Pero era mucho más difícil sacar ese potencial que en una arquitectura mono-procesador. Ojo, el segundo procesador SIEMPRE es una ventaja. A las malas no se utiliza, pero su potencial siempre estará ahí. El problema de Saturn fue que la falta de experiencia de los desarrolladores y la completa falta de herramientas y documentación hizo que en muchos de los casos el segundo procesador no se utilizara, por lo que Saturn quedaba reducida de hecho a un sistema monoprocesador menos potente que la competencia. De ahí la gran diferencia entre los first party y la gran mayoría de los multis

Sí que digo es que el bus compartido era un enorme cuello de botella. Lo que dice Suzuki no es incompatible con que el bus sea compartido (que lo es). Fíjate que dice que la potencia teórica que él estima se de 180% respecto a usar un único SH2. Usando emsamblador y pensando muy bien el código. En teoría, en un sistema en el que ambos procesadores pudieran acceder a memoria en paralelo, ese rendimiento teórico sería más o menos de un 200%. Suzuki ya te está eliminando un 20% de ese rendimiento teórico , y eso que no era precisamente manco.

Ojo, si Saturn hubiera vendido como PSX se habría aprovechado al máximo, se habrían desarrollado tanto las herramientas como el conocimiento necesario para ello. Desde luego que tenían más potencial que el mostrado. Aunque tengo dudas de que lo que no llegó a mostrarse fuera una diferencia enorme, está claro que Saturn mantuvo un 20% por ciento inexplorado como mínimo.

Es que la diferencia entre potencial teórico y realidad puede ser grande. Mirad el caso de PS3. En teoría, sobre el papel, el Cell se iba a comer el mundo. En la realidad sólo le sacaron auténtico provecho los estudios internos de Sony y no al principio de la generación, precisamente. Es un caso bastante similar.

Me encanta este hilo. Un placer leeros!!

____________
Ayúdame a mantener este y otros proyectos, pulsa aquí



Choose a job you love, and you will never have to work a day in your life. (Confucius)

Como siempre me asombro de vuestros conocimientos...oleee!!!