Arquitetura do Sega Saturn – análise prática (2021)
(copetti.org)- O Sega Saturn é um console lançado na transição para o 3D, mas foi projetado com uma estrutura paralela que combina dois CPUs SH-2, SCU, VDP1·VDP2 e subsistemas independentes de áudio e CD, em vez de usar um único acelerador 3D
- Os CPUs eram dois Hitachi SH-2 de cerca de 28,63 MHz em configuração master-slave, mas como compartilhavam o barramento externo, o desempenho não dobrava de forma simples e o desenvolvimento era mais difícil
- Nos gráficos, o VDP1 desenhava sprites baseados em quadriláteros no frame buffer e o VDP2 cuidava da composição de fundos, planos e camadas; isso o tornava forte em 2D, mas com grandes limitações em determinação de superfícies visíveis e transparência no 3D
- O áudio era quase um computador separado, composto por SCSP/Yamaha YMF292, Motorola 68EC000 e 512KB de sound RAM, e graças ao CD-ROM era possível usar samples PCM e trilhas sonoras de alta qualidade baseadas em CD-DA
- Para combater a cópia de CDs, a Sega usou um anel fora da área padrão do CD e uma verificação por SH-1 dentro do drive, mas depois surgiram formas de contorno e execução de homebrew como mod chip, swap trick, PseudoSaturn, Satiator e ODE
Projeto complexo de console na transição para o 3D
- Depois do Mega Drive, o Sega Saturn foi um console que combinava vários elementos de hardware para permitir renderização de polígonos quando necessário, em vez de impor exclusivamente o 3D
- O circuito inteiro é dividido entre vários processadores e quatro subsistemas principais
- Subsistema de CPU: onde ficam o CPU principal, a memória e a SCU
- Subsistema de vídeo: onde ficam os aceleradores gráficos
- Subsistema de áudio: com uma estrutura de processamento de áudio próxima à de um computador separado
- Subsistema de CD-ROM: com uma estrutura fechada por causa do mecanismo anticópia
- Cada subsistema é conectado a um barramento dedicado, e os subsistemas de vídeo e áudio compartilham um mesmo barramento
CPU: dois SH-2 e a SCU
- A Sega escolheu CPUs da família SuperH da Hitachi para os jogos da nova geração e os recursos 3D
- O SuperH era um CPU pensado para uso embarcado, mas já incluía elementos típicos de arquitetura RISC na época
- separa operações de memória e de registrador com uma arquitetura load-store
- oferece barramento de dados de 32 bits e ALU de 32 bits
- fornece 16 registradores de uso geral de 32 bits
- com barramento de endereços de 32 bits, pode endereçar até 4GB de memória
- usa pipeline de 5 estágios para processar várias instruções por etapa
- os primeiros SuperH incluíam uma unidade de multiplicação de 16 bits
- A ISA SuperH segue um projeto RISC, mas todas as instruções têm largura de 16 bits
- como o CPU busca instruções em unidades de 32 bits, ele pode buscar duas instruções por ciclo
- isso reduz o problema de densidade de código típico de arquiteturas RISC
- Também restam limitações típicas do design RISC
- por causa de hazards de controle, o programa precisa considerar o branch delay slot
- o SuperH oferece delayed branch instructions com delay slot incluído
- hazards de dados são tratados com parada automática do pipeline quando necessário
Escolha do SH-2 e estrutura com CPU duplo
- A Sega avaliou que o multiplicador de 16 bits poderia virar gargalo no processamento de grandes volumes de dados em jogos 3D e pediu melhorias à Hitachi
- A Hitachi ampliou a unidade de multiplicação e criou o SH-2 refletindo as exigências da Sega
- De olho nas escolhas de CPU dos consoles concorrentes, a Sega também queria elevar o clock, mas isso era impossível em chips já naquele estágio de fabricação
- A Hitachi já havia acrescentado circuitos mínimos na fase de pesquisa do SH para permitir que vários SH operassem ao mesmo tempo no mesmo sistema, e a Sega adotou uma configuração de 2 chips no Saturn
- A configuração final de CPU reunia ao mesmo tempo potencial de paralelismo e gargalos
- dois Hitachi SH-2 operando a cerca de 28,63 MHz cada
- os dois CPUs eram fisicamente idênticos, mas organizados em estado master-slave
- o CPU master podia enviar comandos ao CPU slave
- como compartilham o mesmo barramento externo, pode haver congestionamento de barramento
- O chip SH7604 incluía recursos para reforçar o desempenho de execução
- pipeline de 5 estágios e ISA SuperH expandida
- unidade de multiplicação de 32 bits
- barramento externo de dados de 32 bits compartilhado
- cache de 4KB
- unidade de divisão de 32 bits
- controlador DMA interno
- suporte a little endian
- Ter dois CPUs não fazia os jogos rodarem duas vezes mais rápido; para paralelismo eficiente era necessário programação complexa levando em conta o barramento compartilhado e o uso de cache
Memória e SCU
- O subsistema de CPU possui 2MB de Work RAM para uso geral
- A Work RAM é dividida em dois blocos
- WRAM-H: 1MB de SDRAM, com acesso mais rápido, e barramento compartilhado com outros componentes
- WRAM-L: 1MB de DRAM, mais lenta, mas com barramento exclusivo do CPU principal
- Além dos dois SH-2, o grupo de CPU também inclui a Saturn Control Unit (SCU)
- A SCU é formada por dois módulos responsáveis por movimentação de dados e auxílio de cálculo
- controlador DMA: arbitra o acesso à WRAM-L entre os três subsistemas sem intervenção do CPU
- DSP: usado como uma unidade geométrica de ponto fixo, executando cálculos de matriz e vetor para transformações 3D e iluminação mais rápido que os SH-2
- O DSP da SCU opera em meia velocidade, tem conjunto de instruções mais complexo e usa a WRAM-L mais lenta e DMA para fetch e store de dados
- A SCU inclui 32KB de SRAM para uso local
Estrutura gráfica: VDP1 e VDP2
- O Saturn usa duas GPUs proprietárias com funções diferentes executadas ao mesmo tempo: VDP1 e VDP2
- No design gráfico da geração 3D, o frame buffer se tornou importante
- a GPU desenha o bitmap da cena em parte da VRAM e depois o codificador de vídeo o exibe
- o tamanho do frame buffer é proporcional à resolução da tela e à profundidade de cor
- por exemplo, 600KB de VRAM podem armazenar um frame buffer de 640×480, 32K cores, 16bpp
- No Saturn, a aceleração de operações vetoriais não fica nos SH-2 em si, mas na SCU
VDP1: sprites baseados em quadriláteros e frame buffer
- O VDP1 desenha sprites com transformações geométricas aplicadas, grava o resultado no frame buffer e depois o entrega ao VDP2 para exibição
- A programação é feita emitindo drawing commands
- ele usa 512KB de RAM dedicada para armazenar comandos, texturas·tiles, tabelas de lookup de cores etc.
- A forma básica é apenas o quadrilátero quadrilateral
- os modelos são compostos por polígonos de quatro vértices, ou seja, sprites
- usa Forward Texture Mapping para mapear pontos da textura ao quadrilátero
- como não há filtragem nem interpolação, o rendering sofre com aliasing
- Entre os efeitos oferecidos estão Flat·Gouraud shading, anti-aliasing, clipping e transparency
- São usados dois chips de frame buffer de 256KB para desenhar a próxima cena em um buffer enquanto o outro está sendo exibido
- quando o rendering do segundo buffer termina, usa-se page flipping para alternar o buffer exibido
VDP2: planos de fundo, composição de camadas e correção de perspectiva
- O VDP2 é especializado em renderizar grandes planos de até 4096×4096 pixels com transformações de rotação, escala e deslocamento
- Ele renderiza on the fly acompanhando o avanço do feixe do CRT, sem frame buffer
- Suporta cor de 24 bits, com até 16,7 milhões de cores
- Também exibe o buffer de saída do VDP1 e pode transformá-lo e misturá-lo com suas próprias camadas
- A composição do frame escolhe uma das seguintes opções
- até quatro planos 2D e um plano 3D
- ou dois planos 3D
- O VDP2 constrói os planos com tile-map e aplica perspective correction ao texture mapping 3D
- Os efeitos disponíveis incluem multi-texturing e shadowing
- ele pode reduzir o brilho dos sprites recebidos do VDP1 e misturá-los com semitransparência
- porém, como recebe apenas um fluxo de sprites sincronizado com a velocidade do feixe do CRT, a codificação e a operação são complicadas
- O VDP2 inclui 4KB de CRAM para converter os valores de indexed colour do VDP1 em RGB de 24 bits
- Embora os planos 3D sejam limitados a dois, o CPU pode usar a VRAM do VDP2 como frame buffer por software para desenhar gráficos 2D e 3D adicionais
Uma máquina gráfica forte em 2D e complicada em 3D
- A capacidade do Saturn para cenas 2D era muito mais ampla que a do Mega Drive ou do SNES, mas esse não era o principal argumento de venda do console
- Em jogos 2D, o VDP1 desenha sprites tradicionais, o VDP2 desenha os planos de fundo e depois compõe a cena final automaticamente
- Em Mega Man X4, o VDP1 cuida do plano de sprites e o VDP2 monta vários planos de fundo
- Usando recursos do VDP2, é possível criar efeitos de cena como ondulação de calor por meio de scaling
- No 3D, pontos fortes e dificuldades aparecem ao mesmo tempo
- havia margem para explorar 8 processadores, mas os desenvolvedores precisavam aprender os recursos e lançar jogos dentro de uma vida comercial curta
- a qualidade dos jogos variava muito conforme o título e a abordagem de cada estúdio
- O Saturn define distorted sprites, quadriláteros de quatro pontos em ângulos arbitrários, e preenche suas superfícies com texture mapping
- Quando CPU e SCU constroem o mundo 3D e o projetam no espaço 2D, os VDPs o renderizam, aplicam efeitos e o enviam à TV
- Qual VDP assumia o rendering principal variava de jogo para jogo
- alguns desenvolvedores deixavam polígonos próximos no VDP1 e fundos distantes no VDP2
- outros criaram técnicas alternativas para fazer o VDP2 desenhar até polígonos próximos
Determinação de superfícies visíveis e limitações de semitransparência
- Ao projetar polígonos 3D em espaço 2D, é preciso distinguir entre os polígonos visíveis pela câmera e os que ficam ocultos
- Esse problema é conhecido como Visible Surface Determination (VSD) e afeta a precisão da exibição do modelo, os efeitos de transparência e o uso de recursos de hardware
- O VDP1 do Saturn não implementa recursos de VSD
- se a geometria não for enviada na ordem correta, a imagem pode ficar corrompida
- A biblioteca gráfica da Sega, SGL, implementa em software o Z-sort, ou algoritmo do pintor
- ela ordena os polígonos do mais distante para o mais próximo com base na distância até a câmera
- depois emite os comandos do VDP1 nessa ordem
- Como o valor de Z-order do Z-sort é aproximado, ainda podem ocorrer defeitos gráficos em ambientes 3D
- Alguns programadores implementavam seus próprios algoritmos no lugar do SGL
- O Saturn consegue renderizar gráficos semitransparentes, mas com muitas restrições
- a mistura de pixels semitransparentes só pode ser tratada pelo VDP2
- o VDP1 envia um buffer já renderizado sem distinguir sprites sobrepostos, então sprites semitransparentes ocultam os sprites abaixo
- o forward texture mapping do VDP1 causa problemas ao aplicar semitransparência em distorted sprites
- desenhar pixels semitransparentes leva seis vezes mais tempo
- Jogos 2D podiam contornar isso usando a propriedade mesh da texture para tornar algumas coordenadas totalmente transparentes
- em sinal de vídeo composto, o padrão mesh fica borrado e cria um efeito que parece semitransparência
- ainda assim, as partes opacas continuam ocultando outros sprites
- Daytona desativa a semitransparência e deixa visível o surgimento repentino do fundo, enquanto Sonic R implementa semitransparência e efeitos de fading com o registrador mix ratio do VDP2 e mudança de níveis de iluminação
Áudio: subsistema de som independente
- Os recursos de áudio do Saturn fazem parte da transição digital da época, em que CD-ROM e sintetizadores por sample passaram a se combinar
- O subsistema de som é composto por SCSP/Yamaha YMF292, Motorola 68EC000 e 512KB de sound RAM
- O SCSP é dividido em dois módulos
- gerador de som multifuncional: processa até 32 canais como samples PCM ou canais FM
- DSP: aplica efeitos de áudio como echo, reverb e chorus
- o PCM suporta samples de até 16 bits e 44,1kHz com qualidade de CD
- O Motorola 68EC000 controla os componentes de áudio e faz a interface com os CPUs principais
- no Saturn, o 68EC000 opera a 11,3MHz e é ligado por barramento de 16 bits
- ele executa o sound driver e opera os módulos periféricos
- Os 512KB de sound RAM armazenam dados de áudio como o sound driver e samples PCM, além de servir como área de trabalho do DSP
- O pipeline de áudio é dividido entre CPU principal, 68EC000, SCU e subsistema de CD
- o CPU principal inicializa os componentes de áudio e carrega o sound driver na sound RAM
- depois ativa o Motorola 68EC000
- durante o jogo, a SCU pode transferir samples PCM do CD para a sound RAM
- o subsistema de CD pode enviar áudio CD-DA não comprimido diretamente ao SCSP
- com a placa Video CD, o áudio comprimido pode ser decodificado na placa e então enviado ao SCSP
- Graças à adoção de CD-ROM e à capacidade de processar PCM, os estúdios passaram a poder gravar e produzir a trilha sonora por conta própria e incluí-la no jogo sem rearranjos
Boot, IPL e shell embutido
- Ao ligar o aparelho, quem entra em ação primeiro é o SMPC (System Management and Peripheral Control)
- O SMPC é um microcontrolador de 4 bits e cuida da inicialização dos chips periféricos, inclusive ligando os dois SH-2 e configurando-os em modo master-slave
- Depois disso, o reset vector do SH-2 master é definido como
0x00000000, e esse endereço aponta para o Initial Program Loader (IPL) na ROM de 512KB - Após inicializar o hardware, o IPL verifica os alvos de boot na seguinte ordem
- se houver um cartucho com código executável, o boot continua por ele
- se houver uma Video CD card, faz boot por ela
- se houver disco, ele verifica se é original
- se for original, inicia o jogo
- se não for original ou não houver disco, executa o interactive shell
- Além dos jogos, o Saturn traz um player de música embutido chamado Multiplayer
- por ele é possível acessar o gerenciador de dados salvos
- se houver Video CD card, também é possível reproduzir vídeo MPEG decodificado pela placa
- A ROM do Saturn não é lembrada principalmente como um conjunto de APIs para desenvolvedores, como a BIOS do PlayStation, mas como IPL
- Ainda assim, a ROM do IPL inclui serviços de System program para gerenciamento de saves, controle de energia e semaphores para sincronização multiprocessador
Mídia de jogos e ambiente de desenvolvimento
- Os jogos oficiais do Saturn são carregados por um drive de CD-ROM 2x
- A mídia é uma variação customizada do Compact Disc, com capacidade de 650MB e conformidade com o padrão ISO 9660
- Muitos jogos incluem faixas de áudio ao lado da trilha de dados para fazer streaming de áudio não comprimido durante a partida
- O CD registra informação em minúsculos pit e land na superfície de policarbonato, restaurando os dados pela leitura da reflexão infravermelha
- O CD usa várias técnicas de codificação e correção de erro para densidade de armazenamento e sincronização
- NRZI grava
1nas transições pit-land - EFM converte combinações de 8 bits em sequências de 14 bits adequadas às limitações dos leitores de CD
- CIRC distribui os dados pelo disco e adiciona redundância para permitir a recuperação de áreas danificadas
- NRZI grava
- O Saturn adota o formato CD-ROM XA
- ele pode armazenar dados, áudio não comprimido e interleaved multimedia tracks
- isso é importante para fazer streaming de áudio e imagem em velocidade razoável mesmo em drives lentos
- a descompressão para reprodução de vídeo exige uma placa Video CD separada
- O ambiente de desenvolvimento era pesado no início, mas depois ganhou ferramentas melhores
- a Sega não forneceu bibliotecas de software e ferramentas de desenvolvimento suficientes, e a documentação inicial também tinha partes imprecisas
- no começo, programação em assembly era importante para obter desempenho aceitável
- depois a Sega passou a fornecer SDK, kits de hardware e bibliotecas de suporte a I/O e gráficos
- os jogos de Saturn eram escritos combinando C com assembly específico de vários componentes
- O gerenciamento de I/O e do RTC fica a cargo do SMPC, controlado por comandos enviados pelos SH-2
Interfaces de expansão
- O Saturn tem vários conectores e interfaces externas
- O cartridge slot na parte traseira do drive é usado oficialmente como armazenamento extra para saves ou como extra RAM
- no Japão e nos Estados Unidos, também foi oferecido modem para conexão online
- Na traseira há um slot para Video CD Card
- ele faz a descompressão MPEG para programas ou jogos compatíveis
- O Communication Connector traseiro é uma interface para a qual a Sega não publicou documentação de desenvolvedor
- a engenharia reversa mostrou que ele está ligado aos pinos MIDI do SCSP e à Serial Interface (SCI) dos dois SH-2
- a Sega lançou um floppy drive que usa essa interface
Anticópia e execução de homebrew
- Como a cópia de CDs era fácil, a Sega implementou proteção anticópia e region locking para controlar a distribuição dos jogos
- A proteção anticópia do Saturn foge deliberadamente do formato padrão de CD
- um gravador de CD comum não consegue fazer uma cópia perfeita de jogos de Saturn
- o leitor de disco do Saturn procura características não padronizadas durante a verificação
- Na borda externa do disco do Saturn há um padrão anormal de dados prensado
- esse padrão cria um anel visível com o rótulo da marca
- o anel fica fora da Program Area e do Lead-out, que são a área de dados padrão
- drives comuns não conseguem acessar nem copiar essa região
- Dentro do drive de CD do Saturn há um processador dedicado SH-1 que verifica a presença do anel de forma independente do CPU principal
- Essa checagem é feita apenas uma vez
- Os métodos tradicionais de contorno focavam em enganar o processo de verificação do disco
- instala-se um mod chip para enganar o leitor de CD independentemente do disco inserido
- o swap trick troca o disco por uma mídia gravada logo após a validação de um disco original
- Mais tarde surgiram formas mais sofisticadas de executar homebrew
- PseudoSaturn usa um exploit do mecanismo anticópia para iniciar jogos em disco sem validação
- em 2022, o fork mais novo Pseudo Saturn Kai passou a ser usado
- em 2016 surgiu um método que aproveita o fato de o add-on Video CD conseguir contornar o drive de CD e injetar código não criptografado no subsistema de CD
- esse exploit de Video CD é vendido como Satiator
- o Optical Drive Emulator (ODE) substitui o leitor de CD por um adaptador SD ou SATA e faz o Saturn acreditar que está lendo um CD, quando na verdade lê imagens de disco
1 comentários
Opiniões no Hacker News
O artigo descreve o projeto como se fosse surpreendente por ter muitos chips, mas é preciso olhar o contexto: não havia nenhuma sinergia entre a equipe japonesa e a americana, e havia uma disputa de liderança
A SEGA JP estava criando um console 2D, enquanto a SEGA US estava criando um console 3D; no momento em que a equipe japonesa estava prestes a vencer essa disputa, o PSX apareceu e, na prática, os dois acabaram sendo fundidos
O resultado foi um console 2D com peças de um console 3D inacabado, o que não faz sentido em termos de design
Para entusiastas de tecnologia ou para quem gosta de ler retrospectivas de desenvolvimento, é um espetáculo; mas, para quem gosta de projetos limpos, é irritante sem fim
Para o gamer comum da época, o essencial era “o arcade na sala de estar”, e o Saturn foi decepcionante; o fato de a SEGA não saber em que lado focar também não ajudou em nada
O artigo da Wikipedia tem mais detalhes: https://en.wikipedia.org/wiki/Sega_Saturn
Uma entrevista com o arquiteto de hardware do Saturn (https://mdshock.com/2020/06/16/hideki-sato-discussing-the-se...) mostra a perspectiva sobre por que aquela configuração de hardware foi escolhida
Basicamente, ele viu a reação ao PSX e entendeu que 3D era o futuro, mas, exceto pela equipe AM2 da SEGA, que fazia jogos de arcade 3D como Virtua Fighter e Daytona USA, a especialidade interna estava nos jogos tradicionais baseados em sprites 2D
Por isso, ele considerou que um console excelente para jogos 2D e também razoavelmente capaz em 3D era o melhor compromisso
A meu ver, o maior erro foi subestimar a rapidez com que a indústria migraria para o foco em 3D
O resultado real das disputas internas na SEGA foi muito mais idiota. A Sega of America queria um projeto mais conservador que o Saturn, usando o Motorola 68020, sucessor do 68000 do Genesis; teria menos desempenho, mas os desenvolvedores estariam mais familiarizados com o hardware
Depois de perder essa disputa, a SOA concluiu que o Saturn era caro demais para vender nos EUA e projetou o 32X, um add-on de 200 dólares para o Genesis
O 32X usa o mesmo processador SH2 do Saturn, mas todos os gráficos eram desenhados por software e sobrepostos aos gráficos do Genesis
O plano inicial era manter o Saturn exclusivo do Japão por 2 a 3 anos e vender o 32X no exterior
A Sega of America gastou uma enorme quantia para gerar interesse pelo 32X e também concentrou seu desenvolvimento interno exclusivamente nele, mas tanto os desenvolvedores quanto a mídia quase não se interessaram pelo 32X em comparação com o Saturn
Quando ficou claro que o 32X não conseguiria sustentar o mercado, a Sega of America lançou o Saturn às pressas para desviar a atenção do 32X; mas, como havia passado o último ano desenvolvendo títulos para o 32X, teve de depender apenas de jogos japoneses, muitos dos quais não se adequavam ao mercado americano
O 32X teve mais jogos cancelados do que lançados, e tudo isso confundiu e irritou desenvolvedores e consumidores
Costuma-se citar que o VDP2 foi adicionado posteriormente para dar suporte a 3D, mas o VDP2 não faz 3D algum; ele cuida de camadas de fundo no estilo Mode 7 do SNES
Mesmo removendo o VDP2, se ignorarmos o fato de que o scanout de vídeo fica a cargo do VDP, o console restante ainda conseguiria fazer 3D bem
Na prática, muitos jogos 3D quase não usam o VDP2
Jogos 2D teriam de renderizar fundos como centenas de sprites, então haveria perda de qualidade, mas seria possível
Por outro lado, se o VDP1 for removido, restam apenas as camadas de fundo 2D do VDP2
Nesse caso não há 3D e também não é possível colocar sprites na tela, tornando-o praticamente inútil até para jogos 2D
Pelo que parece, desde o início o Saturn foi pensado para ter tanto o VDP1 quanto o VDP2, e os dois foram projetados para funcionar juntos
A intenção da SEGA JP parece ter sido, como se vê no projeto final, um console monstro em 2D com capacidades 3D limitadas
Isso não significa que não tenha havido discussões entre a SEGA JP e a SEGA US; as evidências parecem ser consideráveis
Mas não acho que, no último minuto, tenham misturado um projeto japonês com um americano
Como o Saturn foi lançado no Japão 12 dias antes do PSX, também é difícil dizer que o PSX tenha influenciado essa discussão
Por isso cada empresa apresentou uma solução diferente, com prós e contras distintos, mas todas são interessantes de analisar e comparar
É também por isso que este texto foi escrito
https://www.copetti.org/writings/consoles/playstation/
https://www.copetti.org/writings/consoles/nintendo-64/
No gênero de jogos de tiro, o Saturn estava repleto de shoot 'em ups japoneses, e muitos deles eram ports de arcade perfeitos ou quase perfeitos
O Sega Saturn tinha uma arquitetura de hardware bastante complexa
Entendo que dividir as “tarefas” dos jogos entre várias CPUs e processadores dedicados faça sentido do ponto de vista de custo-benefício para escalar, mas isso deve ter influenciado as vendas relativamente fracas do Saturn
Muita gente acabou dizendo que era difícil para as empresas justificarem o investimento de aprender tudo para criar jogos que realmente aproveitassem o hardware
Isso me lembra a frase de Sid Meier: “quem deve se divertir não é o desenvolvedor do jogo, e sim o jogador”; neste caso, talvez os projetistas de hardware é que tenham se divertido demais
Por aqui, o Mega Drive, ou Genesis, foi quase tão bem-sucedido quanto o SNES, se não no mesmo nível, e todo mundo tinha um Mega Drive ou jogava regularmente na casa de amigos
Era um hardware realmente popular
Mas, na geração seguinte, todo mundo tinha um Playstation, e eu só conheci uma criança que comprou um Saturn
Considerando que, por aqui, o Saturn foi lançado alguns meses antes do Playstation, isso é realmente estranho
Não sei se foi porque, na época, o Saturn parecia uma opção inferior, ou se foi preço, problemas de oferta ou algum outro fator, mas o Playstation dominou completamente
Depois disso, a Sega desapareceu
O Saturn tinha o custo de fabricação mais alto entre os três grandes, e ter de igualar o preço do PlayStation virou um desastre financeiro para a Sega
Por causa da parte que diz que “portanto, o VDP1 foi projetado para usar quadriláteros como forma básica, e modelos só podem ser compostos por polígonos de 4 vértices, ou seja, sprites”, os jogos 3D do Sega Saturn davam uma sensação mais angular do que suas versões para PS1
Comparar lado a lado as versões de Resident Evil para Saturn e PS1 é uma boa forma de ver a diferença
No geral, os jogos do Sega Saturn acabaram tendo uma estética peculiar entre os jogos 3D dos anos 90
Também vale mencionar que a emulação do Sega Saturn ficou bem atrás da de outras plataformas
Parece ter sido uma combinação do baixo sucesso no Ocidente com a arquitetura complexa
Mas é verdade que por muito tempo ela foi bem fraca
Para os títulos de que eu realmente gosto, também dá para comprar o jogo original no eBay e sentir que estou apoiando de alguma forma
É muito trabalhoso ficar usando luvas de borracha para tirar o CD da caixa de plástico e depois guardá-lo de novo toda vez, só para preservar o valor do original, mas não quero trocar a experiência do jogo original por emulação
O Sega Saturn tinha vários clássicos escondidos, como Panzer Dragoon Saga, Shining Force III, Burning Rangers, Dragon Force I & II, e até onde sei eles não receberam ports nem remakes
Claro, Saturn Bomberman também não pode ficar de fora
O Saturn e seu sucessor, o Dreamcast, eram muito bons e mereciam ter feito mais sucesso
Na prática, até onde sei, os jogos que existem tanto no Saturn quanto em outras plataformas são casos de ports para o Saturn, e não no sentido oposto
Alguém pode me corrigir se eu estiver errado
Pelo que entendo, a emulação do Saturn também continua complicada até hoje, embora tenha havido bastante progresso na última década
Este é meu vídeo favorito de análise técnica/hacking do Saturn
https://www.youtube.com/watch?v=jOyfZex7B3E
Ver a diversidade dos consoles me lembrou a diversidade da época em que a glória dos computadores domésticos estava desaparecendo, antes do domínio do PC
Alguns dos mesmos OEMs e publishers sobreviveram até hoje
Gostaria de ver isso em um infográfico, e talvez até me dê vontade de fazer um
Gosto do trabalho do Copetti e já o citei antes, mas sempre me parece muito alto nível
Ainda assim, como sei quanto esforço dá para escrever textos assim, sempre parece injusto pedir mais
No fim das contas, a publicidade e o poder financeiro da Sony venceram a SEGA. É só isso mesmo
Claro que a SEGA também cometeu muitos erros quase autodestrutivos
Olhando para os jogos, quais títulos do PSX realmente abalaram o mundo? Resident Evil em 1996 e FFVII em 1997, talvez?
O Saturn também teve jogos matadores, especialmente em 1996, então, pessoalmente, não acho que o problema tenha sido a biblioteca
A dificuldade de programar também não explica tudo: uma geração depois, os desenvolvedores lidaram bem com o Playstation 2, e o Dreamcast era fácil de aproveitar, mas quando a SEGA o descontinuou, todo mundo o abandonou
Nos EUA, a base de usuários era decente; sobre a Europa, não sei
Também havia uma questão de simpatia dos consumidores pela SEGA, mas, olhando para os problemas de confiabilidade dos sistemas da Sony e da MS, talvez nem tanto
O 360, em especial, teve problemas bem sérios, mas isso não prejudicou em nada a sobrevivência de longo prazo do console
O SEGA CD, pelo menos nos EUA, não foi um fracasso
Sempre foi um produto premium, um tanto desnecessário, mas legal, e tinha ótimos jogos, embora não tivesse um killer app
Foi bem-sucedido para a SEGA
O 32X foi, sim, uma enorme barbeiragem para todos os envolvidos, mas não acho que, no nível do consumidor comum, sua existência tão curta tenha destruído o Saturn sozinho
Nos EUA, acho que as pessoas compram qualquer coisa se o marketing for bom
O marketing do Saturn nos EUA foi péssimo
A SEGA perdeu o rumo e jogou fora tudo que tinha feito o Genesis ser mais bem-sucedido que o SNES
Dá para discutir tecnologia e detalhes sobre o que funcionou ou não no console, mas, na prática, o que matou o Saturn foi a falha de marketing e a ausência de um Sonic de verdade tanto no lançamento quanto depois
1997 foi um ano incrível, com FF7, FF Tactics, Tekken 3, Symphony of the Night e outros
Boa análise. Ainda tenho o Sega Saturn original que possuo desde 1996 e, de vez em quando, ligo para tomar uma bomba de nostalgia.
Ele ainda funciona perfeitamente, exatamente como no dia em que tirei da caixa.
A estrutura do hardware pode ter ficado bem complexa, mas é impossível não gostar da confiabilidade dos consoles antigos.
Os consoles mais modernos que usei nos últimos anos superaqueceram ou quebraram de outras formas, então é difícil dizer o mesmo deles.
Com a entrada da Sony e da MS, a redução de custos na confiabilidade dos consoles já começou, e chegamos ao que temos hoje.
Erros de leitura de disco no PSX e no Playstation 2 eram muito comuns e graves mesmo na época.
Mas, quando as pessoas percebiam, já tinham uma porção de jogos e simplesmente compravam outro console.
Já que o assunto é a arquitetura estranha da Sega, há também um vídeo recente do MattKC em seu segundo canal sobre o 32X.
Se você não conhece o 32X, era um módulo estranho que se encaixava no slot de cartucho do Genesis para rodar uma linha separada de jogos de 32 bits.
Essencialmente, eram dois consoles funcionando juntos, então era outra situação em que duas CPUs cooperavam para gerar a saída de vídeo.
Ao conectar diretamente o cabo de vídeo, ele descobriu que, se cortasse o sinal de vídeo de um dos aparelhos, conseguia obter apenas a saída renderizada pelo outro lado.
O próprio 32X emitia a renderização 3D, enquanto o Genesis fornecia gráficos 2D como menus, HUD e sprites.
https://www.youtube.com/watch?v=rl9fjoolS2s