SEGASaturno - Saturn, SEGA y Videojuegos

Hilo destinado a la recopilación de información contrastable, y debate abierto al respecto de la potencia técnica del sistema.

Las especificaciones generales la mayoría nos las sabemos, ya que están al alcance de cualquier wikia:

Procesadores (8)

- Dos Hitachi SH2 32-bit RISC @ 28.6MHz.
- Un Hitachi SH1 32-bit RISC.
- VDP 1 32-bit video display processor.
- VDP 2 32-bit video display processor.
- Saturn Unidad de Control (SCU).
- Motorola 68EC000 procesador de sonido.
- DSP procesador de sonido.

Memoria

- 2 Megabytes (16 megabits) RAM.
- 1.54 Megabytes (12 megabits) VRAM (Vídeo RAM).
- 540 Kilobytes (4 megabits) Audio RAM.
- 540 Kilobytes (4 megabits) CD-ROM Caché.

Video

- VDP 1 32-bit video display processor para sprites, polígonos.
- Dos 256KB frame buffers para efectos de scaling y rotación.
- Mapeado de texturas.
- Goraud Shading.
- 512KB caché para texturas.

- VDP 2 32-bit background and scroll plane video display processor background engine.
- 5 simulataneous scrolling backgrounds.
- 2 simultaneous rotating playfields.

- 200,000 Texture Mapped Polygons/Second.
- 500,000 Flat Shaded Polygons/Second up to 60 frames per second animation.
- 24-bit true color graphics.
- 16. Million Available Colors.
- 320x224 resolución mínima, 720x576 máxima resolución.

Audio

- Yamaha 24-bit Digital Signal Processor @ 22.6MHz.
- Motorola 68EC000 sound processor @ 11.3MHz.
- 32 PCM (Pulse Code Modulation) Channels.
- 8 FM (Frequency Modulation) Channels.
- 44.1 khz Sampling Rate.

Capacidad

- CD-ROM (2X) 320 Kilobytes/Second Transfer Speed.
- Audio CD Compatible.
- CD+G Compatible.
- CD+EG Compatible.
- CD Single (8 cm CD) Compatible.
- Optional - Video CD, Photo CD, EBook, Digital Karaoke.
- Optional - 512KB Memory Cartridges for game save.

Input/Output

- High speed serial communications port.
- Internal 32-bit Expansion port.
- Internal Multi AV Port for optional Video CD (MPEG) adapter.
- Composite Video/Stereo (Standard).
- NTSC RF (Optional).
- S-Video Compatible (Optional).
- RGB Compatible (Optional).
- HDTV Compatible (Optional).
- Analog Control Pad (x2).

Todo este baile de números se distribuye en la placa más o menos de la siguiente manera:


http://i.imgur.com/KivAOL9.jpg (imagen ampliada)

Quien quiera informarse en más profundidad y detalle acerca del funcionamiento del hardware puede acceder a esta excelente fuente de consulta:

http://videogamereview.tripod.com/saturn/specs.html#TOP

http://segaretro.org/Sega_Saturn (de esta web recomiendo tomar con "pinzas" la información, es un site muy fanboy)

Y después de semejante lectura, nada como ver ejemplificadas y comentadas todas esas explicaciones técnicas en los propios juegos:


YouTube Link


__________________________________________________

Llegados a este punto podríamos pensar que ya tenemos suficiente material contrastado para estudiar. Sin embargo lo abarcado hasta ahora sigue dentro del ámbito de lo "amateur"; gente corriente con algún conocimiento en la materia que saca sus propias conclusiones al respecto, pero que ultimadamente no es nada que cualquiera de nosotros no pudiese aportar si nos pusiésemos a investigar a fondo el tema. Es por ello que he decidido expandir un poco más el contenido aportando testimonios contrastables de gente que ha programado directamente para Saturn, como Yu Suzuki o Keishi Okayashu, ambos importantes desarrolladores durante la primera etapa de la consola.

Información extraída de revistas Next Gen del año 1995:


http://imgur.com/oL5BjDf

Citar:

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.

Citar:

En AM2 usamos C para las primeras etapas, y ensamblador después de eso. Conseguimos mantener las CPUs gemelas corriendo a una velociad 1.8 veces mayor que la velocidad en un sólo chip, eso habría sido imposible usando sólo C.

Yu Suzuki hablando de sus primeras experiencias programando en Saturn.


http://imgur.com/WfNU62H

Citar:

No pudimos portar software directamente desde el Model 1 a la Saturn. El V-60 y el SH-2 (super H) son chips completamente diferentes. El código original necesitaba muchísimo trabajo para hacerlo funcionar.

Keishi Okayashu, líder de proyecto en la conversión del primer Virtua Fighter hablando de la diferencia entre las arquitecturas de Saturn Model 1.

Citar:

Pienso que será difícil desarrollar software para la ST-V. No es que crea que sea un mal hardware, simplemente estoy más interesado en máquinas de gama alta. No obstante debido a su bajo coste, ST-V se convertirá en el nuevo buque insignia de SEGA en el mundo de las máquinas recreativas.

Yu Suzuki opinando sobre la placa ST-V.


http://imgur.com/ISARKGG

Citar:

... es más difícil crear programas y sistemas operativos efectivos para un sistema multi-CPU. Es posible para algunos programadores de gran talento sacar a flote todo el potencial de dos CPUs; pero no es un entorno ideal para la mayoría.

Pienso que el sistema ideal sería mono-CPU ejecutando el mismo poder de procesamiento que uno multi-CPU.

http://imgur.com/8xsLgA

Citar:

NG: ¿Cómo de díficil consideras que es trabajar con la Saturn para los desarrolladores third party?

Mr. Suzuki: La nueva versión del sistema operativo y soporte de apoyo al sistema (librería gráfica de SEGA) que SEGA va a lanzar es muy poderosa, y debería hacer más fácil que nunca el desarrollo de juegos para la Saturn.

Citar:

NG: Desde una perspectiva tecnológica, ¿cúal es el punto fuerte de Saturn en la guerra del hardware?

Mr. Suzuki: Opino que la función más importante en un juego es el procesamiento de imagen en tiempo real. El hardware de Saturn es fuerte en términos de interacción en este tipo de procesamientos.

Citar:

NG: ¿Usted cree que lo que hemos visto hasta ahora es tan sólo una fracción del poder potencial de la Saturn?

Mr. Suzuki: Sí, eso creo.

__________________

De momento no he encontrado un scan o entrevista directa sobre lo que comentaba de Nextmare de que Yu Suzuki dice que que Virtua Fighter 2 empleaba tan sólo el 66% de las capacidades reales de la Saturn, al igual que datos cien por ciento fiables acerca de que las imágenes de aquellos famosos modelos de VF 3, pero estoy en ello.

Conclusiones rápidas...


A bote pronto entiendo que a la Saturn se le puede "meter mano" de las siguientes maneras:

- Utilizando un solo SH-2 y ambos VDPs.
- Utilizando un solo SH-2 y un solo VDP, pero ultimadamente con el VDP 2 sacando el outpout.
- Utilizando los dos SH-2 y cualquiera de los VDP.

Y a nivel de transformación de geometría las rutinas posibles serían:

- Un sólo SH-2 dirigiendo y el controlador de memoria calculando los vértices e iluminación.
- Dos SH-2 en configuración "Maestro-Esclavo" ayudándose mutuamente.
- Sólo con el DSP del controlador de memoria.
- ¿Con los SH-2 + el DSP?.

Luego, se nota mucho que a Yu Suzuki no le hacía mucha ilusión el hardware de la Saturn; se le ve el plumero cuando le preguntan qué opina acerca de ST-V y dice que tsé, no está mal, pero que el es un "pijo" que prefiere máquinas de alto standing como la Model 2 o 3, algo por otro lado muy normal si tenemos en cuenta que el sector ARCADE era su ámbito natural, y la mayor parte de recreativas espectaculares llevan su firma. Además que es muy sospechoso el cambio de actitud de una entrevista a otra en HI-TECH, huele a que los de marketing le pidieron que se contuviese con sus opiniones técnicas neutrales, y barriese un poco más para casa.

Mismamente yo no he entendido qué diantres quiso decir con esto:

Citar:

Opino que la función más importante en un juego es el procesamiento de imagen en tiempo real. El hardware de Saturn es fuerte en términos de interacción en este tipo de procesamientos.

¿Procesamiento de imagen en "tiempo real"? ¿Interacción? ¿Eso lo cualo es? Porque a mi entender TODOS los gráficos consisten en "procesamiento de imagen en tiempo real"; luego o no se expresó bien, o yo he traducido muy rudamente.

También deja patente que en AM2 solían programar con un mix de C y ensamblador, pero está demostrado que esto no garantiza siempre buenos resultados: las conversiones del primer Virtua Fighter y Daytona U.S.A son un desastre, y están programadas en gran medida por él, y a bajo nivel. Supongo que es por lo que dijo Nextmare de que esos juegos sólo emplean el VDP-1 para literalmente el 99% de cosas. Esto, entre muchas otras cosas, es algo que me gustaría comprobar en emulador y subir al hilo.

Pero bueno, con Virtua Fighter 2 se lucieron y callaron bocas: 704x448i, 60 fps, modelos poligonales decentes, y bitmaps muy aparentes en un juego que mira de tú a tú al Tekken 3 de PlayStation tanto en lo gráfico como en lo jugable. De hecho a nivel técnico le gana en aspectos clave.

Sega Rally también es un prodigio de la programación dentro del sistema, ya que no se utilizó durante su desarrollo el nuevo sistema operativo.

P.D: El hilo se irá actualizando conforme se vaya encontrando y contrastando información relevante al respecto.

Gran trabajo de documentación Cyclops!! A mi humilde entender creo que los desarrolladores de Sega fueron aprendiendo sobre la marcha a utilizar el hardware de Saturn. muy potente si.... pero complicado de pantalones. Lo que si creo es lo que dice el Mister Suzuki: que de Saturn no se exprimió todo su potencial....

Solo nos queda preguntarnos lo siguiente: ¿juegos como Virtua fighters 2 y Burning Rangers es el tope de lo que daba Saturn, o aun le quedaba mas poder?.....

Muy interesante el hilo.

Hay una cosa que me llama la atención: Potencial teórico VS Realidad.

Creo que es muy, muy difícil establecer algo como el "potencial teórico" de Saturn. Precisamente por la complejidad de su arquitectura. La gente tiende a pensar en el potencial de cada una de sus partes y suponer que el potencial teórico final sería la suma de los potenciales de sus partes. Pero no es así. Como bien se explica en varias partes de tu post, la arquitectura de Saturn tiene muchos cuellos de botella, pero además son cuellos de botella relativos: Dependen del uso que se le quiera dar a la máquina. El hecho de que Virtua Fighter 2 pueda hacer semejante despliegue técnico no quiere decir que eso mismo sea posible en otros juegos. A mí me parece muy complicado establecer "qué podría hacer Saturn teóricamente", al menos en el terreno de las 3D.

La arquitectura de Saturn al final obliga a tomar compromisos. Se le puede sacar mucho partido, pero siempre será renunciando a algo más. A no ser que tu tipo de juego se adapte a la perfección a alguna de las posibles configuraciones de utilización del hardware, será así.

Me parece una recopilación de datos técnicos de la máquina, para mi entender, definitiva. Gran trabajo.
Concuerdo con Jasvy en su puntualización.
Yo últimamente ando probando juegos que desconocía de PSX, y a veces no puedo evitar pensar:
"pufff, creo que esto en saturn no se podría hacer, o no se vería igual"
Sobretodo con los juegos más tardíos o grandes producciones.

tr909 escribió: [Ver mensaje]

Solo nos queda preguntarnos lo siguiente: ¿juegos como Virtua fighters 2 y Burning Rangers es el tope de lo que daba Saturn, o aun le quedaba mas poder?.....

Según Nextmare Yu Suzuki dijo en una entrevista que Virtua Fighter 2 emplea tan sólo el 66% de las capacidades del sistema, pero claro esto puede prestarse a muchas interpretaciones, porque más que el "cúanto", yo creo que primero conviene enterarse del cómo aprovecha la Saturn un juego de lucha con un entorno 100% controlable por el programador, a diferencia de por ejemplo un juego con un escenario más abierto, y múltiples enemigos. O sea que a lo mejor ese 66% es casi el tope de lo que podría dar de sí la consola en un fighting game, pero hace usos mediocres del sistema en cuanto a físicas realistas, transparencias, etc. Es todo muy complejo de dilucidar.

De hecho mira lo que dice Jasvy:

Jasvy escribió: [Ver mensaje]

Creo que es muy, muy difícil establecer algo como el "potencial teórico" de Saturn. Precisamente por la complejidad de su arquitectura. La gente tiende a pensar en el potencial de cada una de sus partes y suponer que el potencial teórico final sería la suma de los potenciales de sus partes. Pero no es así. Como bien se explica en varias partes de tu post, la arquitectura de Saturn tiene muchos cuellos de botella, pero además son cuellos de botella relativos: Dependen del uso que se le quiera dar a la máquina. El hecho de que Virtua Fighter 2 pueda hacer semejante despliegue técnico no quiere decir que eso mismo sea posible en otros juegos. A mí me parece muy complicado establecer "qué podría hacer Saturn teóricamente", al menos en el terreno de las 3D.

Completamente de acuerdo. Al igual que otros hardwares mal diseñados como la PlayStation 2, o la Nintendo 64, Saturn se pone muchas zancadillas a sí misma; pero lo que en determinados entornos son "zancadillas", en otros puede ser una "muleta". Y luego están factores como el que plantea Yu Suzuki, o el mismo Fonzie en MD; qué partes conviene ejecutarlas en ensamblador, y cúales es otras lo más sensato sería usar C. Y por lo que se ve para que la Saturn brille es necesario picar mucho código en esambaldor. Las diferentes librerías, etc, cada sistema es un mundo. Por ejemplo en PlayStation meterte con ASM es una perdida de tiempo, porque con C puedes hacer practicamente lo que te salga del ojal sin más incovenientes que el de tu propia habilidad programando.

He abierto el hilo a propósito con ese título, ya que aparte de para recopilar información contrastable, en parte también lo que me gustaría es que todos vayamos flexibilizando conceptos que tenemos demasiado rígidos en la cabeza, y que creemos son inamovibles como están.

Que por cierto ya que estamos, no sé si viste este tema:

http://www.segasaturno.com/portal/a...tes-vt8963.html

Cosas como el modo 16:9 real en Exhumed/Power Slave demuestran que empleando la máquina exactamente de la misma manera, Saturn aun podía ofrecer resultados más flexibles.

lanjackie escribió: [Ver mensaje]

Me parece una recopilación de datos técnicos de la máquina, para mi entender, definitiva.

Si con "definitiva" te refieres a que por fin tenemos un hilo fijo en Segasaturno donde ordenarlo todo, y debatir acerca de ello expandiéndonos más allá del típico "VS" con la PlayStation que casi nunca nos conduce a ningún lado más allá de los piques, entonces estoy de acuerdo contigo. Ahora yo espero que a nivel de contenido la cosa se expanda mucho, MUCHÍSIMO más.

A ver si entre todos conseguimos completar poco a poco este maravilloso puzzle técnico que es la Sega Saturn. Ojalá se pase algún entendido de verdad, y colabore un poco con nosotros.

Yo de momento ya me he registrado en un par de foros de scene, a ver todo lo que puedo sacar en claro.

Para mi todo esto me suena a ciencia ficción. Asi que poco puedo aportar, a parte de leer (sin entender mucho )

Es un hilo muy interesante

Será un hilo muy interesante en el que compartir información.

Entrevista a Toby Gard, uno de los responsables del primer Tomb Raider de Core. Comparto la imagen porque en ella habla, primero, de que Tomb Raider podría haber sido exclusivo de Sega Saturn (que hubiere pasado si…) y, en segundo lugar, que el hecho de que se programase y lanzase primero en Saturn, fue positivo en lo técnico para la versión de Playstation, porque pudieron corregir muchos bugs que sí estaban en la versión PSX. Estos son detalles que muchas veces no tomamos en cuenta cuando comparamos técnicamente las versiones de Saturn vs … llevándonos a conclusiones que muchas veces no son veraces.



(Retro Gamer España, abril 2017, nº 19, pag. 67)

PD: Este hilo tiene mucho potencial, hagámoslo bien. Intentad referenciar a la fuente del articulo original cuando compartáis una imagen, por si se quiere consultar o por situarlo en su contexto temporal. Gracias!!

Muy interesante el hilo señores, dentro de poco tendré algo más de tiempo y me gustaría aportar algún scan de revistas que tengo descargadas porque recuerdo varias entrevistas donde se hacía alusión a datos técnicos de programación en Saturn, sobretodo semanas antes de comercializar un juego donde se concedía la típica entrevista con los desarrolladores.

lanjackie escribió: [Ver mensaje]

Me parece una recopilación de datos técnicos de la máquina, para mi entender, definitiva. Gran trabajo.
Concuerdo con Jasvy en su puntualización.
Yo últimamente ando probando juegos que desconocía de PSX, y a veces no puedo evitar pensar:
"pufff, creo que esto en saturn no se podría hacer, o no se vería igual"
Sobretodo con los juegos más tardíos o grandes producciones.

Me pasa lo mismo, llevo ya dos años casi donde he probado mucho juego de PS que en su día de chaval ni podía atreverme a soñar y me recorre la misma sensación mientras juego. Algunos ya tan solo por la fluidez con la que se mueven y el despilfarro pirotécnico de efectos de luces se hacen casi casi imposibles de soñar en la 32 bit de Sega.
Por otro lado también hay muchos que hubieran sido (con toda mi ignorante sabiduría) posibles en Saturn: MDK.

Y no quería dejar de comentar el hito histórico que esta llevando a cabo una persona que esta desarrollando para Saturn usando el Jo engine:


YouTube Link


Este vídeo es de hace 4 días, lleva en este proyecto tan sólo 2 meses y ya lo ha probado en una Saturn con esos resultados que vuestros ojitos ven. Esto en sólo 2 meses a ratos una persona totalmente amateur!, ¡en Saturn!

El tipo comenta que tan sólo usa una CPU y todo esta programado en C (lenguaje que usa el Jo engine), tiene esperanzas de optimizar aún mucho más el juego a medida que va conociendo el funcionamiento interno de la consola y las posibilidades del programa de desarrollo.


YouTube Link


Este video es anterior donde muestra el castillo de Peach en un entorno totalmente 3D aunque con bastantes bugs, recordar que solo llevaba 1 mes de desarrollo. De nuevo algo majestuosamente increíble y maravilloso.

Con todo esto, la pregunta que me corroe internamente como aficionado incondicional de Saturn es;

¿Sería posible a día de hoy con estas nuevas herramientas de desarrollo, y las futuras (usb mod) sobrepasar ese techo técnico visto en su día de forma profesional en Saturn?.

Fandu escribió: [Ver mensaje]

¿Sería posible a día de hoy con estas nuevas herramientas de desarrollo, y las futuras (usb mod) sobrepasar ese techo técnico visto en su día de forma profesional en Saturn?.

Por supuesto. Mira Paprium... En su día los equipos de desarrollo no tenían mucha información ni herramientas. Pero lo que menos tenían era tiempo. Dale tiempo a un equipo de desarrollo y te sobrepasará el techo técnico de cualquier cosa lanzado en el ciclo de vida comercial de una consola. Precisamente el problema de Saturn era que sacar buenos resultados requería mucho más tiempo y esfuerzo que hacerlo en PSX. Pero con tiempo... se podrían hacer cosas muy buenas, claro que sí. Tiempo para pasar a ASM cualquier código, para optimizar al máximo el uso de los buses, para estudiar de cero y sin presiones temporales cómo utilizar de la mejor manera los dos chips gráficos y los dos procesadores.

Pero aún así hay que tener en cuenta que la infernal arquitectura de Saturn siempre será un obstáculo.

Me apetece hablar un poco del Hitachi SH-2, también conocido como "Super H 2", ya que diseño de la Saturn al margen por lo visto era un mircro de muy alto rendimiento para la época en determinadas áreas. De hecho no parece ser casualidad que en esos años compañías como CAPCOM o PSIKYO sustituyesen en sus placas más potentes a los procesadores de la familia Motorola 68.000 por los SH-2 (CPS-3 y Psikyo SH2). Es más, a día de hoy se sigue utilizando en controladores de red y automóviles.

Expongo lo que opinaba de él uno de los principales ingenieros:

Citar:

El SH-2 tiene una alta eficiencia de cálculo. Para ampliar, reducir, y rotar gráficos 2D y 3D es muy rápido. Aparte de las estaciones de trabajo, ningún chip puede cambiar coordenadas tan deprisa.

El principal jefe técnico que perfeccionó el chip.

Las conversiones a la Saturn de las placas encabezadas por ese micro se antojaron muy fáciles en Saturn (Strikers 1945 II), de ahí que desde hace un tiempo exista un proyecto en la scene del que todavía apenas nadie sabe nada, el cual consiste en llevar el siguiente título a la Saturn:



Están convencidos de que es posible usando el cartucho de expansión con 4 MB de RAM extra. La cosa sería más o menos:

- "Copypaste" del código SH-2 (la CPS 3 tiene un Hitachi a 25 Mhz, los de Saturn rulan a 28 Mhz).

- Redibujado coherente para adaptar el aspect-ratio desde los 384x224 hasta los 352x224 de la Saturn.

- Animaciones y sonidos metidos A SACO en la RAM, y aunque estiman que quizás no quepan todas, y el muestreo posiblemente haya que reducirlo, los resultados serán muy satisfactorios.

- Pistas de audio en el CD rom (como en el ARCADE).

Ya veremos en qué queda todo.

Yo creo que para determinados tipos de juegos 3d saturn es muy potente.
Si puedes usar planos del VDP2 para los escenarios y el suelo o lo que sea te ahorras un monton de poligonos que se pueden usar para otras cosas y estos poligonos pueden tener mejores texturas al tener que dibujar menos el VDP1 y el resultado de usar planos del VP2 suele ser mejor que con poligonos incluso de psx eso se puede ver en juegos que estan en psx y saturn como el grandia lo que saturn hace con el vdp2 psx tiene que hacerlo con poligonos y suele estar peor, sobretodo las texturas. Ademas si se usa para el suelo no existe el efecto de dibujado en el horizonte, al menos en el suelo y así se puede esconder mejor el poping.
los efectos que hace el VDP2 son muy buenos. Ejemplos los suelos y agua con VDP2 de los panzer dragoon o los escenarios del last bronx. De hecho el fill rate de saturn es superior al de psx si sumamos el vdp1+vdp2 pero inferior si miramos solo el vdp1.


Vamos que para segun que juegos saturn sería incluso mejor que psx en 3d. Ahora si, si todo tienen que ser triangulos como en Gran Turismo por ejemplo en eso si que gana psx pero para juegos en los que saturn pueda usar el VDP2 de forma intensiva y coherente como los panzer dragoon yo creo que el resultado es mejor en saturn y sigue siendo 3d a fin de cuentas un plano del VP2 tambien es un poligono y se puede mover en todas las dimensiones.

Y sobre lo de la dificultad para programar para 2 cpus, eso lo compro a medias, hay montones de recreativas de sega y no de sega que usan doble cpu y no veo que Yu Suzuki se haya quejado solo de la ST-V. Vamos que saturn no fue ni de lejos la primera maquina de juegos con doble cpu. Es evidente que es mejor una cpu unica si esta tiene la misma potencia que la suma de las otras dos pero no es el caso los dos SH2 en conjunto son mas potentes que la cpu de psx. La ventaja en 3d de psx esta en el "geometry engine" no en la cpu.

Una pregunta ¿Alguien sabe si el DSP de saturn se puede usar para calculos de geometria? ¿Algún juego lo ha usado? Porque en el Atari Falcon si se puede y la mejora es enorme.

LIV escribió: [Ver mensaje]

Una pregunta ¿Alguien sabe si el DSP de saturn se puede usar para calculos de geometria? ¿Algún juego lo ha usado?

Sí que se puede usar para operaciones matriciales, y según segaretro su rendimiento en MIPS es superior al de los dos Hitachi SH-2 juntos:

Citar:

SCU DSP

- SCU math coprocessor: Geometry DSP @ 14.31818 MHz, 32‑bit fixed‑point instructions. Parallel units: 32/48-bit ALU (arithmetic logic unit), 48/64‑bit Multiplier, 32-bit instruction decoder.

- Instructions: 6 parallel instructions/cycle (one instruction per unit/bus), 85.90908 MIPS (6 MIPS/MHz).

- Capabilities: Matrix and vector calculations, 3D point transformations, lighting calculations, fixed-point calculations, faster than SH-2, can use DMA to directly fetch and store vertex data, floating-point operations, geometry transformations, voxel rendering acceleration, fast coordinate transformations, lighting computations, transparency calculations.

https://segaretro.org/Sega_Saturn/Technical_specifications

Recomiendo la lectura del artículo a los interesados en el hardware de la Saturn. Resulta que la potencia de cálculo combinada de los dos SH-2 es de 74.454536 MIPS (37.227268 MIPS cada uno). Teniendo en cuenta que para el cálculo de geometría en el mejor de los casos ni siquiera van a utilizartoda la potencia de un solo procesador, las más de 80 MIPS potenciales del DSP se antojan como un caramelito muy a tomar en cuenta.

La pregunta del millón es; ¿si su capacidad del cálculo era tan potente, porqué no se utilizó más a menudo?

Y yo me respondo con lo único que he encontrado, de nuevo en Segaretro:

Citar:

Notas: Solo se puede programar con lenguaje ensamblador, más difícil de programar que SH-2

Sólo admite que le metan mano mediante ensamblador, el cual tiene un "dialecto" todavía más jodido que el del Hitachi SH-2. Recordemos que ni siquiera el mismísimo Yu Suzuki se atrevía a meterse totalmente a pelo con el ASM de los SH-2, programando gran parte del código en C, no me quiero ni imaginar lo que será intentar lidiar con este DSP face to face.

Respondiendo a tu otra pregunta decirte que supuestamente Grandia utiliza el DSP para apoyarse, aunque no sabría concretarte en para qué, pero vamos, polígonos hay y muy sólidos para lo que se estilaba en esa generación:



Lo comentó Wesker hace muchos años en este hilo, aunque parece confundirlo con el Yamaha, ahora mismo me hace dudar:

http://www.segasaturno.com/portal/v...&t=4388&start=9

Y si preguntas hoy día en SEGA-16 mucha gente dirá lo mismo. Quizás los emuladores puedan ayudarnos a concretar más al respecto.

Sobre el resto de tu comentario bueno... No quisiera convertir este hilo en el enésimo y tóxico "Saturn VS PlayStation". Sólo decirte que efectivamente en la consola de SEGA hay que hacer distinción entre usar a saco el VDP1 para la geometría de todo el entorno (contexto en el que queda en inferioridad frente a PS), y emplear sabiamente el combo VDP1 + VDP2 para generar la escena completa, que es cuando el potencial de Saturn florece en todo su esplendor.

Porque un entorno "3D" no sólo tiene porqué estar compuesto al 100% con formas poligonales:



En esta imagen los únicos polígonos/quads que hay son los de los luchadores. El resto son bitmaps 2D con efecto de volumen generados por el VDP2 los cuales va escalando y/o rotando, incluído los pseudo vectores 3D del suelo, y lo cierto es que quedan de puta madre.

En cambio en Tekken 3 si bien vemos personajes mejor modelados, animados, y sombreados, con algún que otro efecto de transparencia en los golpes, los escenarios son postales 2D pegadas al fondo, lo cual provoca una impresión bastante cutre a día de hoy:



Son formas distintas de componer la escena tridimensional.

Si sólo usas polígonos PlayStation normalmente dará mejores resultados por defecto.

En cambio si combeas ambos Vdps con tino, Saturn no sólo se pone a la par en términos visuales, sino que hasta puede ofrecer resultados más atractivos en determinados contextos.

Yo no se mucho de cosas tecnicas pero me ha agradado mucho ver este post, es bueno aprender todos los pormenores tecnicos de Saturn.

Ahora bien me quedo con este comentario de Jasvy.

Jasvy escribió: [Ver mensaje]

En su día los equipos de desarrollo no tenían mucha información ni herramientas. Pero lo que menos tenían era tiempo. Dale tiempo a un equipo de desarrollo y te sobrepasará el techo técnico de cualquier cosa lanzado en el ciclo de vida comercial de una consola. Precisamente el problema de Saturn era que sacar buenos resultados requería mucho más tiempo y esfuerzo que hacerlo en PSX. Pero con tiempo... se podrían hacer cosas muy buenas, claro que sí. Tiempo para pasar a ASM cualquier código, para optimizar al máximo el uso de los buses, para estudiar de cero y sin presiones temporales cómo utilizar de la mejor manera los dos chips gráficos y los dos procesadores.

Pero aún así hay que tener en cuenta que la infernal arquitectura de Saturn siempre será un obstáculo.

Un ejemplo claro de esto lo hizo el Sonic Team en su vida con Sega Saturn, quizas por ser el equipo de los mayores hits comerciales de Megadrive es que tuvieron mayor margen de trabajo, para que hasta pudieran no pensar en Sonic por un par de años.

Consideremos por ejemplo la creacion de Nights tomo un poco mas de un año, cuando la mayoria de estudios no tenian tanto tiempo de desarrollo, ni digamos del Desarrollo de Burning Rangers que si bien ahi el equipo se dividio en dos ya que se inicio a trabajar en Sonic Adventure tambien primero para Saturn y luego que pasarlo a Dreamcast, pero hablamos de un desarrollo que duro casi dos años, ni decir el de Sonic que duro mas tiempo con todo y su mudanza de plataforma.

Siendo que Sega ahi peco un poco de falta de paciencia, si tenian que vender su consola, y hacer juegos pero para eso estaba tener una mejor relacion comercial con las Thirds sin decir de cosas ya dichas como la publicidad entre otras cosas, la verdad ver todos esos factores deja mucho que pensar.

Hace poco descubrí un dato interesante; resulta que a mí siempre me extrañó que conversiones desde placas supuestamente inferiores como la SEGA Y-Board funcionasen a 30 fps en Saturn, mientras que los originales corren a 60 gloriosos frames.

Son los casos de Power Drift:




Y Galaxy Force 2:




El cual además también sufre ralentizaciones extra. Ambos ARCADES de 1988.

Al principio pensé que todo esto era debido a que estas conversiones no las hizo Rutubo Games, los cracks encargados de conversionar Out Run, Space Harrier, y After Bunner 2 para la Saturn con excelentes resultados. Pero cuando me puse a investigar un poco me di cuenta de que no era ese el problema, sino el VDP2 de la consola:



Resulta que a pesar de sus numerosas virtudes, el segundo procesador de vídeo en la Saturn sufre bastante intentando subir por encima de los 30 fps a la hora de mover, escalar, y rotar 2 planos de fondo con efecto tridimensional:

Citar:

El VDP2 dibuja planos infinitos en 3D de hasta 4096 × 4096 píxeles a 30 FPS.

https://segaretro.org/Sega_Saturn

Esto no significa que la Saturn sea débil, sino que la placa SEGA-Y era un MONSTRUO del scaling y la rotación para 1988:

Citar:

* Main CPU: 3× MC68000 @ 12.5 MHz (16-bit & 32-bit instructions @ 6.563 MIPS).

Planos gráficos; tres capas de sprites:

- Capa B-sprite (plano frontal): Prioridad en la parte superior, basada en el sistema de sprites System 16B (buffer de línea)

- Capa Y-sprite (plano posterior): se conecta a una rotación de pantalla completa, relleno grande , framebuffers de doble buffer (basados ​​en X Board) que pueden rotar completamente
Capa de gradiente de cielo (fondo): plano de mapa de bits

- Capa de degradado de cielo (fondo): plano de mapa de bits.

Capacidades de sprite / texturas, lista de sprites, sombras y resaltados, desvanecimiento de paleta, rotaciones de color, diferentes niveles de luminosidad, zoom y escalado de sprites completos en ambos planos de sprites, rotación completa de framebuffer sprite en plano Y, doble buffer , doble buffer de línea de almacenamiento intermedio en el plano B (512 píxeles), buffer de marco de doble buffer en el plano Y.

Capacidad por plano:

- Sprites Y: 2048 sprites / texturas, 64 KB de RAM de atributo (32 KB bank por framebuffer), 16 bytes por entrada.

- B sprites: 256 sprites/texturas, 4 KB de RAM de atributo, 16 bytes por entrada.

- Sprites / texturas por segundo: 2176 (1 FPS) a 130,560 (60 FPS).

https://segaretro.org/Sega_Y_Board

Estamos hablando de un bicharraco que tiene tres Motorola 68000 a 12,5 MHz dedicados sabe Dios a qué, y que al igual que la Neo Geo sólo utiliza sprites a saco, ni planos de scroll ni hostias, puro fill rate de figuras.

No obstante a pesar de todo yo le doy cierto margen de beneficio de duda a la Saturn, después de todo el Out Run, otro "scaling racer" es capaz de correrlo a 60 fps, el doble que el original.

En el futuro tengo planeado mirar todos estos detalles con los emuladores, para precisar más acerca de como construye la Saturn el entorno escalable/rotable en las diferentes conversiones.

Nota: Dada la naturaleza "Wikia" de segaretro recomiendo su lectura con precaución, y contrastando en la medida de lo posible la información allí vertida.

Interesante, como siempre.

Esperamos más!

Yo también era de los que pensaban que el tema era por no tener al desarrollador adecuado. Sin ir más lejos, la versión Sega Ages de Galaxy Force II para Sega Saturn no es ni siquiera de desarrollo japonés, sino que la hicieron los húngaros de Appalosa Interactive (creadores de Ecco the Dolphin, entre otros).

De todas formas, con Rutubo Games detrás como fue en el caso de los otros Sega Ages igual se hubiera podido obrar el milagro.

Muy interesante la información que aportas Cyclops y veo que poco a poco vas moderando un poco tu mala percepción inicial respecto a las capacidades gráficas 3D de Saturn, en comparación con PSX.

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....
No creo que ningún pequeño estudio sea capaz de sacar el máximo rendimiento a esta maquina con un bajo presupuesto, salvo que la misma Sega se animara a hacer algo ... igual que van a empezar a hacer mandos inalambricos.

Cyclops escribió: [Ver mensaje]

No obstante a pesar de todo yo le doy cierto margen de beneficio de duda a la Saturn; después de todo el After Bunner 2 rula a 60 fps en la consola:

Bien es cierto que en este caso el entorno es mucho menos complejo, pero de cualquier manera imagino que la Saturn compondrá la escena de la misma forma: Vdp1 para el plano de sprites, y Vdp2 para planos de fondo y marcadores.

Sin olvidarnos del Out Run, el cual en versión Saturn ofrece la posibilidad de jugarlo al doble de velocidad que la placa original (60 fps).

esas dos conversiones puedo dar fe que me impresionaron sus resultados, After Burner 2 en Saturn
es solidisimo y frenetico! lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ciertamente la bestia consolera era un toro dificil de domar, es el ciclo natural de muchas consolas en general
donde las primeras entradas demuestran un potencial simple vs sus ultimos juegos ya cambiaron/superaron
con creces. Se me viene a la cabeza los relevos de memoria adicional que usaron y me hacen recordar
los trabajos de joyeria que se manda la PC Engine Duo con un hardware aun mas limitado y antiguo.

Nekketsu escribió: [Ver mensaje]

lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ojo, que Power Drift en Saturn sigue siendo una delicia visual y un juegazo increíblemente divertido, simplemente sucede que la placa SEGA-Y es un MONSTRUO del scaling y la rotación, algo así como la versión 2D de la Model 3, y para igualar sus resultados habrá que hilar muy fino programando en la consola de SEGA.

Al final yo creo que se trata de con el equilibrio y acierto con el que combines ambos VDP, después de todo aún dando por bueno el hecho de que a la Saturn le cueste manipular varios fondos a 60 fps, Rutubo Games mejoró el rendimiento de la placa del Out Run en la versión para Saturn:


YouTube Link


Y vale que en este ARCADE el plano de la carretera no rota/vira de posición a vertical/diagonal en ningún momento, ni el hardware es tan potente como la Y-Board, pero acelerar el scaling de sprites hasta 60 fps no es moco de pavo, y el After Bunner 2 sí que gira el fondo y rula a 60 fps en Saturn:



Lo cual me lleva a preguntarme si en Rutubo Games usaban A SACO el VDP1 para casi todo fundiendo tasa de relleno y marginando al VDP2, viceversa, o bien eran unos magos combinando los dos procesadores gráficos; ¡Ah qué putada no tener Pc ahora para poder emularlos y ver cómo trabaja la Saturn!

Por otro lado está el Galaxy Force II, y aunque este sí que huele a conversión chapucera, sigue siendo sospechoso que las dos únicas conversiones desde la SEGA-Y adolezcan del mismo problema...

¿O es que acaso Out Run y After Bunner 2 en Saturn rulan un plano a 60 fps y otro a 30?

En cualquier caso yo le doy el beneficio de la duda a la 32 bits de SEGA para marcarse una conversión de Power Drift a 60 fps totales.

Hendrix Saturn escribió: [Ver mensaje]

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....

Quizás en materia poligonal no, pero en cuanto a las posibilidades 2D de Saturn afortunadamente estas son Sota, Caballo, y Rey; simplemente tenemos que ordenar el puzzle y ver qué juegos fueron programados con el culo y cúales no. Los emuladores son una excelente herramienta para estos menesteres.

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

El Galaxy Force II de Saturn tambien es jodidamente espectacular a 60Hz.

Cyclops escribió: [Ver mensaje]

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

vamos Cyclops, quiero ver tu analisis de Fighters History Dynamite y de Groove on Fight, conversiones
bien poco populares pero muy bien trabajadas ese review me tienta observar con ese nivel detalle y cuidado
que le das.

Hace poco salió el último reportaje de Digital Foundry Retro dedicado a una franquicia de SEGA, en este caso hablamos de Panzer Dragoon, centrándose en sus dos primeras entregas, todos los ports y formas de poder jugarlos incluída la emulación:

https://www.youtube.com/watch?v=4GQ..._toocbU9cND7U-A

Dentro de su habitual línea de "autopsia" tecnólogica, me gustaría destacar como muestran el modo en que se empleó inteligentemente el hardware de la Saturn en estos juegos, repartiendo armónicamente la carga gráfica entre los dos procesadores de vídeo en la consola.

En Panzer Dragoon el VDP2 de la máquina (planos de fondo, outpout final, etc) se encarga de generar las superficies bajas tales como el agua, la línea de horizonte, y el plano del cielo:


(Chulísimo el efecto del oleaje únicamente a base de manipular el tilemap).

Esto que a muchos podrá parecerles una tontería es un ahorra-recursos de la hostia para la Saturn, ya que no gasta ni una pizca de la potencia del VDP1 para cálculos poligonales, ahorrándose este último toda su tasa de relleno para dibujar la geometría. En PlayStation hacer lo mismo gastaría mucho fill rate de su procesador gráfico, ya que la consola de Sony dibuja la escena ENTERA a base de triángulos indiferentemente de si está generando un entorno poligonal o bidimensional, además de tener que calcular todos los efectos de oleja/rotación/escalado con un mismo chip mientras que en Saturn lo hacen entre 2, por lo que un port de PD a PS se antoja muy difícil ya que las cosas que Saturn hace por separado la Play las tendría que hacer a golpe de fundir tasa de relleno de su chip gráfico, la cual es superior a las del VDP1 y VDP2 por separado ojo, pero cuando se combinan con inteligencia la cosa se equilibra bastante.

En cambio a la consola de SEGA lo único que le cuesta es un background de fondo que ocupa apenas unos kb en la memoria de vídeo, y un plano infinito que el VDP2 escala o rota a placer sin despeinarse:


(Haters gonna hate!!!).

Y con esta "tontería" ya tiene la mitad de la escena dibujada con su rendimiento geométrico INTACTO

Por su parte el VDP1 libre de esas otras tareas se concentra exclusivamente en dibujar los polígonos, texturizarlos, y generar sprites/patrones de marcadores/texturas sueltas:


(Muy curioso el modo en que emplean texturas deformadas para simular el reflejo distorsionado en el agua).

Lamentablemente a pesar del buen juicio y creatividad con los que los diseñadores utilizaron los dos procesadores gráficos, se nota que Panzer Dragoon es un juego de primera hornada para la Saturn, ya que comparte el mismo defecto que otros contemporáneos suyos dentro del sistema como puedan ser Daytona U.S.A, o Tomb Raider; un frame-rate muy bajo que en raras ocasiones sobrepasa los 20 fps:


(Por suerte para controlar a un dragón de movimiento lento y "orgánico" 20 fotogramas por segundo son más suficientes para una buena experiencia).

Se notaba que todavía no le tenían cogido el punto cara a organizar los Hitachi SH-2 trabajando juntos en las fases de aplicación y transformación; recordemos que hasta el mismísimo Yu Suzuki tardó en cogerles el "tranquillo", ya que sus dos primeros trabajos al sistema resultaron ser conversiones muy mediocres en lo técnico, mientras que en Virtua Fighter 2 ya demostró estar más ducho sacándole jugo al sistema. Imagino que también tendría que ver el hecho de no disponer aún del nuevo sistema operativo que llegaría un año más tarde.

Sin embargo Panzer Dragoon Zwei es un ejemplo de lo contrario; título de segunda hornada que al igual que otros juegos de 1996 como Daytona U.S.A Championship Circuit Edition, mostraron un rendimiento muy superior a sus predecesores, demostrando que la Saturn todavía una consola a explotar. Concretamente PDZ subió la tasa de fotogramas hasta 30 fps en juego, y nada menos que a 60 fps en las cut-scenes generadas por el motor del juego. Pero lejos de quedarse ahí, lo más impresionante de todo es que partiendo de un uso similar de los VDPs al de su primera parte, Panzer Dragoon Zwei también ponía en pantalla mayor número de polígonos que la anterior entrega:


(Cielo, horizonte, y suelo desaparecen porque desactivan a propósito el VDP2, no es ningún bug).

Es que me parece exagerado que aun habiendo aumentado la velocidad del juego hasta 30/60 fps dependiendo del contexto, todavía les sobrase capacidad de proceso para incrementar también la geometría, es que no me jodas, o pulieron muchísimo el código, o bien... ¿emplearían el misterioso DSP para algunos cálculos?. Miedo me da averiguar que lograron en el Panzer Dragoon Saga.

Cuando tenga tiempo me hago unos GIF del uso salvaje que le dieron al VDP2 en Panzer Dragoon Zwei; festival de escalados, rotaciones, y efectos flipantes.

Nekketsu escribió: [Ver mensaje]

Cyclops escribió: [Ver mensaje]

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

vamos Cyclops, quiero ver tu analisis de Fighters History Dynamite y de Groove on Fight, conversiones
bien poco populares pero muy bien trabajadas ese review me tienta observar con ese nivel detalle y cuidado
que le das.

Mientras tanto aquí te dejo el gameplay @60Hz


YouTube Link

Cyclops escribió: [Ver mensaje]

Nekketsu escribió: [Ver mensaje]

lo de Power Drift me parecio una sorpresa, esperaba una conversion asi de potente.

Ojo, que Power Drift en Saturn sigue siendo una delicia visual y un juegazo increíblemente divertido, simplemente sucede que la placa SEGA-Y es un MONSTRUO del scaling y la rotación, algo así como la versión 2D de la Model 3, y para igualar sus resultados habrá que hilar muy fino programando en la consola de SEGA.

Al final yo creo que se trata de con el equilibrio y acierto con el que combines ambos VDP, después de todo aún dando por bueno el hecho de que a la Saturn le cueste manipular varios fondos a 60 fps, Rutubo Games mejoró el rendimiento de la placa del Out Run en la versión para Saturn:


YouTube Link


Y vale que en este ARCADE el plano de la carretera no rota/vira de posición a vertical/diagonal en ningún momento, ni el hardware es tan potente como la Y-Board, pero acelerar el scaling de sprites hasta 60 fps no es moco de pavo, y el After Bunner 2 sí que gira el fondo y rula a 60 fps en Saturn:

Spoiler: [ Mostrar ]

Spoiler: [ Ocultar ]

Lo cual me lleva a preguntarme si en Rutubo Games usaban A SACO el VDP1 para casi todo fundiendo tasa de relleno y marginando al VDP2, viceversa, o bien eran unos magos combinando los dos procesadores gráficos; ¡Ah qué putada no tener Pc ahora para poder emularlos y ver cómo trabaja la Saturn!

Por otro lado está el Galaxy Force II, y aunque este sí que huele a conversión chapucera, sigue siendo sospechoso que las dos únicas conversiones desde la SEGA-Y adolezcan del mismo problema...

¿O es que acaso Out Run y After Bunner 2 en Saturn rulan un plano a 60 fps y otro a 30?

En cualquier caso yo le doy el beneficio de la duda a la 32 bits de SEGA para marcarse una conversión de Power Drift a 60 fps totales.

Hendrix Saturn escribió: [Ver mensaje]

Desde mi humilde opinión solo tengo una cosa clara, nunca sabremos cual es el techo de esta consola ....

Quizás en materia poligonal no, pero en cuanto a las posibilidades 2D de Saturn afortunadamente estas son Sota, Caballo, y Rey; simplemente tenemos que ordenar el puzzle y ver qué juegos fueron programados con el culo y cúales no. Los emuladores son una excelente herramienta para estos menesteres.

Nota: Reitero que toda la información que leáis en Segaretro la cojáis con «pinzas» y la contrastéis en la medida de lo posible, últimamente estoy viendo ediciones muy fanboys y sesgadas manipulando datos, cuando no inventándoselos, mezclando verdades con mentiras. Mucho ojo.

Muy buena e interesante info. Sea como sea son juegos que a 60Hz dan una sensación increíble de velocidad, sobretodo el OutRun:


YouTube Link



En cuanto a los Panzer Dragoon, son un buen ejemplo de la evolución del rendimiento. Del 1 al Zwei se nota toda esa mejoría de rendimiento gráfico y jugable:


YouTube Link



YouTube Link


Y ya empezaron a entrar a otro nuevo nivel de rendimiento... con morphings espectaculares, si hubiera tenido 2 años más de optimización las librerías y kits de desarrollo de SEGA se hubieran visto cosas muy tochas:


YouTube Link

Edit Se puede borrar

No soy moderador, y tampoco quiero sonar descortés, pero en adelante te agradecería que en este hilo no dobleposteases tan seguido en un mismo día después de que alguien se haya currado un aporte largo como he hecho yo esta misma mañana, debido a que se pierde el visonado enseguida innecesariamente. El gameplay de los Panzer Dragon podrías haberlo metido en el otro post simplemente editando.

Gracias, muy interesantes tus vídeos como siempre.

Ups, perdona. Lo he leído ahora mismo. Edito este último y que lo borren. Lo siento.

Edit Se puede borrar

Cyclops escribió: [Ver mensaje]

Es que me parece exagerado que aun habiendo aumentado la velocidad del juego hasta 30/60 fps dependiendo del contexto, todavía les sobrase capacidad de proceso para incrementar también la geometría,

Me acabo de quedar loco. ¿Que aun sobraba potencia? Estoy deseando ver el Saga. Realmente se le podría haber sacado mucho más jugo a la Saturn, no son sueños de fanboy XD

Me encanta este hilo!

Hay un salto de calidad brutal del primero al segundo. Al igual que otros videojuegos de Saturn.

Cyclops escribió: [Ver mensaje]

¿emplearían el misterioso DSP para algunos cálculos?. Miedo me da averiguar que lograron en el Panzer Dragoon Saga.

El misterioso DSP no lo es tanto, en el link que pasaste en posts anteriores de Sega Retro te dicen básicamente para que se debería usar:

Capabilities: Matrix and vector calculations, 3D point transformations, lighting calculations, fixed-point calculations,[49] faster than SH-2,[52] can use DMA to directly fetch and store vertex data, floating-point operations, geometry transformations, voxel rendering acceleration, fast coordinate transformations, lighting computations,[53] transparency calculations[54]
Notes: Can only be programmed with assembly language, more difficult to program than SH-2[49]

Y digo "debería usar" pues lo más probable es que casi ningún estudio externo a Sega lo utilizase, dadas las dificultades para programar en él. Ya lo he pasado antes, pero recomiendo encarecidamente la lectura de siguiente blog para entender en que condiciones se programaba para la arquitectura paralela de Saturn: "The target machine is the Sega Saturn, which has two SH2 Risc microprocessors and one 68000. Currently we only use the Master SH2, the slave SH2 will be used when we get around to figuring out how" que en español viene a significar “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“ (http://cowboyprogramming.com/2010/0...he-sega-saturn/).

El problema de Saturn no fue su potencia y si me apuráis, tampoco lo fue su arquitectura, su verdadero problema fue el hecho de que Sony (con Namco y Psygnosis como actores principales) se esforzaron para reventar a Sega el modelo de generación que tenían previsto para Saturn.

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!!

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