Arquitetura do Sega Saturn

Uma análise prática por Rodrigo Copetti

Traduzido por Eugênio Lloyd

Edição clássica - Última atualização: 7 de julho de 2024

Idiomas disponíveis: 🇬🇧 - English, 🇧🇷 - Português (Brasil), 👋 - Adicionar tradução


Sobre esta edição

A edição "clássica" é uma versão alternativa à "moderna". Não requer Javascript, CSS de primeira linha ou HTML complicado pra funcionar, o que a torna ideal para leitores que utilizam ferramentas de acessibilidade ou navegadores antigos. Por outro lado, usuários de leitores de eBook podem dar uma olhada na edição eBook.

Esta edição é idêntica no quesito de conteúdo. No entanto, widgets interativos foram simplificados para trabalhar com HTML puro, embora estes ofereçam um link para o artigo original, caso o leitor queira experimentar a "versão completa".

Como sempre, este artigo está disponível no Github, para que os leitores possam reportar erros ou propor mudanças. Também existe uma lista de leitura de apoio disponível, para ajudar na compreensão dessa série. O autor também aceita doações para ajudar nas melhorias de qualidade dos artigos atuais e dos que ainda virão.


Índice

  1. Imagens de suporte
  2. Uma breve introdução
  3. CPU
    1. As ramificações
    2. A Sega não está satisfeita
    3. O produto final
    4. Uma escolha dividida de memória
    5. O terceiro (sim, mais um) processador
  4. Gráficos
    1. A Oferta da Sega
      1. VDP1
      2. VDP2
    2. Definindo o problema
    3. Como um poderoso console 2D
      1. Sprites
      2. Backgrounds (Planos de fundo)
      3. Resultado
    4. Como um console 3D desafiador
      1. Modelagem 3D
      2. Processamento de pixels
    5. Os novos designs
    6. Uma introdução ao problema da visibilidade
    7. A questão da transparência
  5. Áudio
    1. A oportunidade
  6. Sistema Operacional
    1. Shell interativo
    2. Sem BIOS?
  7. Jogos
    1. O Compact Disc (CD)
    2. Desenvolvimento
    3. E/S
    4. Métodos de expansão
  8. Anti-pirataria & Homebrew
    1. Derrota
  9. Isso é tudo pessoal
  10. Copyright and permissions
  11. Fontes / Continuar lendo
  12. Contribuir

Imagens de suporte

Modelo

Image
O Sega Saturn, lançado em 22/11/1994 no Japão
Image
O Sega Saturn, lançado em 11/05/1995 nos EUA e em 08/07/1995 na Europa

Placa-mãe

Image
Placa-mãe
Exibição da revisão "VA8", a qual inclui todos os componentes numa única placa.
Os chips de RAM restantes ficam encaixados na parte traseira
Image
Placa-mãe com partes importantes rotuladas

Diagrama

Image
Diagrama de arquitetura principal

Uma breve introdução

Bem vindo à era 3D! Bom… mais ou menos. A Sega teve um sucesso considerável com o Mega Drive, então não havia razão para forçar os desenvolvedores a criar jogos em 3D ainda.

No caso de algum desenvolvedor querer usar a dimensão adicional, a Sega adaptou certas partes do hardware para permitir também o desenho de polígonos. Claro que isso não iria sair de controle, não é?


CPU

Assim como seus competidores mais próximos, que estiveram cheios de opções ao longo da febre do RISC, a Sega precisou passar por todos os dilemas de escolher um novo fornecedor que pudesse erguer a próxima geração de jogos (inclusive aqueles com capacidades “3D”). No final, a empresa optou por uma CPU recente, cujo criador estava desesperado atrás de algum adotante: a Hitachi SuperH, ou “SH”.

Ainda que, de início, a nova criação da Hitachi tenha focado em aplicativos embarcados, ela estreou artifícios modernos, como [1]:

Além disso, o SuperH apresenta um novo conjunto de instruções, chamado SuperH ISA, o qual, mesmo com a adoção do design RISC, tem todas as suas instruções no tamanho de 16 bits. Isso é uma surpresa, pois essa CPU opera com palavras de 32 bits, portanto seria esperado que as instruções tivessem o mesmo comprimento. Ainda assim, a Hitachi conseguiu encaixar seu conjunto de instruções usando metade do tamanho. Esse formato não apenas reduz o tamanho dos programas: como a CPU busca por instruções em lotes de 32 bits, ela pode captar duas instruções num único ciclo. Num geral, essa técnica de comprimir o conjunto de instruções ajudou a lidar com uma preocupação comum das arquiteturas baseadas em RISC, chamada “densidade de código”. Essas arquiteturas acabavam requerindo mais instruções (e, portanto, mais memória) para executar as mesmas tarefas do que sistemas não RISC.

As ramificações

Por outro lado, as desvantagens dos designs RISC ainda estão presentes no SuperH, como os hazards de controle. Por consequência, os programas precisam incluir espaços para atraso de desvio condicional, para evitar erros de cálculo. Para remediar a situação, o SuperH possui instruções de atraso de desvio condicional, que são instruções de desvio pré-equipadas com um espaço de atraso [3].

Hazards de dados também estão presentes, mas não são resolvidos pelo programador ou pelo compilador: a CPU automaticamente irá reter a pipeline quando for necessário.

A Sega não está satisfeita

No entanto, nada disso impediu a Sega de manifestar sua insatisfação com o produto final. Isso ocorreu principalmente por causa do pequeno multiplicador de 16 bits, percebido como um funil para o processamento de grandes quantidades de dados (uma nova necessidade dos jogos 3D). Por isso, a Hitachi sintetizou uma segunda revisão, com uma unidade multiplicadora estendida e outros requisitos da lista da Sega [4], o que levou a uma nova CPU chamada SH-2.

Image
Os dois chips SH-2 encontrados no Sega Saturn

Ainda assim, a Sega não pôde ficar parada após ouvir a escolha de CPU que seus competidores haviam feito. Ela pediu à Hitachi que aumentasse a taxa de clock do SH-2 — uma tarefa impossível uma vez que o chip estivesse pronto para fabricação. Por sorte, a Hitachi tinha outro truque na manga: multiprocessamento. Durante a fase de pesquisa do SH, o time havia adicionado circuitos mínimos capazes de permitir que o SH funcionasse com outros SHs dentro de um mesmo sistema ao mesmo tempo. Ao ouvir isso, a Sega decidiu que o Sega Saturn teria uma configuração de dois chips. E o resto é história.

O produto final

Com as origens explicadas, vamos dar uma olhada no produto entregue.

O console tem não uma, mas duas CPUs Hitachi SH-2 rodando a ~28.63 MHz cada [5]. Ainda que sejam idênticas fisicamente, elas funcionam num estado master-slave, onde a primeira deve enviar comandos para a segunda. É possível que atinjam certo grau de paralelismo, ainda que ambas dividam o mesmo barramento externo [6] (o que pode levar a congestionamento).

A Hitachi preparou diferentes variantes do SH-2 e as vendeu como parte de uma série chamada “SH7600”. Todas elas possuem [7]:

O chip específico selecionado para este console, o “SH7604”, contém as seguintes adições [8]:

É importante ressaltar que ter duas CPUs não quer dizer que os jogos irão rodar duas vezes mais rápido! Na prática, porém, isso requer uma programação muito complexa, que administre com eficiência CPUs que dividam o mesmo barramento. Portanto, o uso organizado do cache tem um papel crucial nesse console.

Uma escolha dividida de memória

O Sega Saturn contém um total de 2 MB de RAM para uso geral, chamada Work RAM (WRAM). Esses dois mega são divididos entre dois blocos bem diferentes:

O terceiro (sim, mais um) processador

Parece que, surpreendentemente, duas CPUs SH-2 ainda não eram o bastante para a Sega. Então, para acelerar o processamento de vetores (ao custo de maior complexidade), o console abriga um coprocessador adicional, o Saturn Control Unit, ou “SCU”.

É um chip composto de dois módulos [9]:

Pelo lado positivo, a SCU vem com 32 KB de SRAM para uso local. Do lado negativo, a SCU não é capaz de acessar a WRAM-L.


Gráficos

Como o Saturn é o primeiro “console 3D” analisado para esta série, vamos primeiro ver as mudanças fundamentais de design que abriram caminho rumo à nova geração de gráficos 3D:

A Oferta da Sega

O console inclui duas GPUs proprietárias, cada uma servindo a diferentes propósitos ao trabalhar simultaneamente. Alguém pode argumentar que as novas GPUs são uma evolução do clássico VDP, enquanto outros podem dizer que é uma total reformulação… Eu acho que é um pouco de cada.

Com isso dito, vamos dar uma olhada nos dois chips.

VDP1

Image
Arquitetura do VDP1.

O Video Display Processor 1 (VDP1) é um chip que desenha sprites com transformações geométricas [10]. Os resultados são gravados num frame buffer, o qual em resposta é transmitido para o VDP2 para exibição.

O chip é programado através do envio de “comandos de desenho”. Assim sendo, os programadores têm 512 KB de RAM dedicada para guardar esses comandos de desenho e os materiais requeridos (texturas/blocos, tabelas de cores, etc).

Por consequência, o VDP1 foi construído para usar quadriláteros como primitivas, o que significa que ele pode apenas compor modelos usando polígonos (sprites) de 4 vértices. O chip aplica Forward Texture Mapping parta conectar pontos da textura no quadrilátero. Ele não vem com nenhuma técnica de filtro/interpolação, então os cálculos ficam sujeitos a aliasing.

O VDP1 também proporciona esta seleção de efeitos:

Dois chips de frame buffer de 256 KB estão disponíveis para desenhar, ao mesmo tempo, novas cenas do jogo, sem quebrar a que estiver sendo exibida. Quando o buffer secundário termina de ser desenhado, o VDP1 começa a transmitir o segundo no lugar (page-flipping), e o ciclo continua.

VDP2

Image
Arquitetura do VDP2.

O Video Display Processor 2 (VDP2) se especializa em renderizar planos grandes (4096×4096 pixels) com transformações (rotação, escala e translação) aplicadas aos mesmos [11].

Mais importante, o VDP2 renderiza na hora (sem frame buffer) tal como as engines baseadas em tiles anteriores. Ele pode exibir até 16.7 milhões de cores (24 bits). Este chip é também responsável pela exibição do buffer do VDP1, que também pode ser transformado e/ou misturado com as camadas do VDP2. O “frame” do VDP é composto de até quatro planos 2D e um plano 3D; ou dois planos 3D.

Esse chip utiliza tile-maps para compor planos, e faz a correção de perspectiva para o mapeamento de texturas 3D. Esse é um método mais sofisticado, que leva em conta o valor de profundidade para computar rotações.

Os efeitos disponíveis incluem multi-texturação (mapeamento de mais de uma textura por polígono) e sombreamento. Com este último, após receber sprites gerados pelo VDP1, o VDP2 consegue reduzir o brilho deles e mesclá-los com meia-transparência. Porém o VDP2 recebe apenas um fluxo de sprites do VDP1 (no mesmo passo do raio da CRT), então essa função tende a ser complicada de codificar e operar.

Esse chip também abriga 4 KB de RAM de cores (CRAM), que é usada para traduzir os valores customizados de cor do VDP1 (cores de índice) para cores RGB de 24 bits.

Por fim, ainda que o VDP2 seja limitado a dois planos 3D, nada impede a CPU de usar a VRAM dele como uma área de frame buffer para desenhar gráficos 2D ou 3D adicionais em software.

Eu recomendo dar uma olhada nas fontes (ao fim do artigo) caso essa seção tenha chamado sua atenção, já que os VDPs têm muitas outras peculiaridades que estão além do escopo desse artigo.

Definindo o problema

Como você pode ver, a arquitetura do subsistema gráfico é bem complexa, e portanto é interpretada de forma diferente a depender da necessidade:

Como um poderoso console 2D

As capacidades do Saturn em desenhar cenas em 2D eram imensas comparadas com as do Mega Drive e do SNES, ainda que não fossem o principal atrativo comercial do console.

Sprites

Image
Mega Man X4 (1997).
Plano de sprites do VDP1.

Nesse caso, o VDP1 tem a tarefa de traçar sprites tradicionais sem aplicar qualquer distorção 3D.

A CPU configura o VDP1 gravando por cima de seus registradores e preenchendo sua VRAM com comandos e tiles. O processo também pode ser acelerado graças ao controlador DMA.

Backgrounds (Planos de fundo)

Image
Plano 2D 1.
Image
Plano 2D 2.
Image
Plano 2D 3.
Mega Man X4 (1997). Planos de fundo do VDP2.

O VDP2 é então instruído a desenhar os planos de fundo. Esses, junto com a camada de sprites, são automaticamente mesclados para formar uma cena totalmente colorida.

A parte de comando é fundamentalmente similar à do VDP1: Os programadores têm os registradores e a VRAM para configurar como precisarem.

Algumas funções do VDP2 podem ser exploradas para a criação de cenários mais realísticos, tal como o redimensionamento usado para simular uma onda de calor (ver “plano 2D 2”).

Resultado

Image
Mega Man X4 (1997). Os planos mesclados (Tadaaa!).

Não tem muito mistério aqui: o VDP2 é o responsável pelo último passo, que é enviar o sinal processado para o codificador de vídeo.

O VDP2 opera em sincronia com o raio do CRT, o que quer dizer que suas computações correspondem aos pixels que serão exibidos na próxima scanline.

Como um console 3D desafiador

Aqui é onde o Saturn brilhou e sofreu ao mesmo tempo. Ainda que esse console tivesse oito processadores para se explorar, no fim tudo era uma questão de:

Por esse motivo, a maior parte dos jogos acabava variando drasticamente de qualidade, já que cada estúdio trazia sua solução individual.

Modelagem 3D

Image
Virtua Fighter Remix (1995).
Modelos 3D dos personagens, sem texturas nem fundo. Repare nas primitivas usadas na construção dos modelos.

Até agora haviam sido usados quadriláteros individuais regulares para formar sprites e/ou planos de fundo. Mas e se agruparmos múltiplas primitivas irregulares e as ordenarmos para formar uma figura mais complexa? É assim que surgem os modelos 3D.

Simplificando, consoles 2D clássicos como o Super Nintendo organizam seus gráficos (fundos e sprites) em áreas mais ou menos retangulares. Em alguns casos, tais como o do Mode 7, os programadores podem providenciar uma matriz de rotação para aplicar transformações sobre algumas dessas áreas. O Saturn, pelo contrário, permite a definição de quadriláteros de 4 pontos com ângulos arbitrários entre suas bordas (a Sega chama isso de “sprites distorcidos”). Então, as capacidades de mapeamento de texturas do VDP pinta a área do quadrilátero com uma textura, esta sendo escalada de acordo com a forma do polígono.

Quanto às operações de que um jogo 3D necessita, as CPUs e a SCU recebem a função de formular um mundo 3D e projetá-lo num espaço 2D. Daí, ambas as VDPs recebem o comando para renderizá-lo, aplicar efeitos e finalmente transmiti-lo para a TV.

Processamento de pixels

Image
Virtua Fighter Remix (1995).
Cena renderizada com modelos 3D e planos de fundo.

Qualquer um dos VDPs pode desenhar esse novo espaço (projetado em) 3D e estampá-lo com texturas e efeitos. Agora, qual chip fica “encarregado” disso varia de jogo para jogo.

Certos jogos usavam o VDP1 prioritariamente para desenhar os polígonos mais próximos, deixando o VDP2 para o processamento de cenários mais distantes. Outros encontravam curiosas soluções para encarregar o VDP2 de desenhar polígonos mais próximos (portanto aliviando a carga de geometria do VDP1). O desafio está em projetar um mecanismo eficiente que possa exibir gráficos impressionantes enquanto mantém uma framerate aceitável.

Os novos designs

Estes são alguns exemplos de personagens que foram redesenhados para o console. Os modelos são interativos, tente mexer com eles!

Image Image Image Modelo interativo disponível na edição moderna
Sonic em Sonic R (1997).
185 quadriláteros.
Image Image Image Modelo interativo disponível na edição moderna
Tails em Sonic R (1997).
254 quadriláteros.

Ainda que o Saturn só seja capaz de desenhar quadrângulos, você logo percebe que esses modelos exibem dois triângulos ao invés de um único quadrângulo no modo “wireframe”. Isso porque o formato usado para codificar esse modelo (gITF, um padrão aberto de modelagem 3D moderna), de forma que seu dispositivo moderno possa renderizá-lo, não tem suporte a quadrângulos até o momento em que esse texto foi escrito. Recomendo mudar para o modo “surface” para observar os quadrângulos.

De certa forma, isso demonstra o quão difícil é para a tecnologia gráfica atual reproduzir seus predecessores de 30 anos atrás!

Uma introdução ao problema da visibilidade

Quando polígonos 3D são projetados num espaço 2D, é crucial determinar quais polígonos são visíveis da posição da câmera e quais ficam ocultos no plano de trás [12]. Senão os modelos não são desenhados corretamente, efeitos como transparência parecerão “quebrados” e, principalmente, recursos de hardware são desperdiçados. Esse processo é mais conhecido como Visible surface determination (determinação de superfície visível) ou “VSD”, e é um problema fundamental no mundo dos gráficos computadorizados. Há múltiplos documentos publicados que descrevem algoritmos de abordagem a esse problema em diferentes estágios do pipeline gráfico. Alguns dão resultados bastante precisos, e outros trocam essa precisão por uma melhor performance.

Diferente de equipamento acadêmico/profissional, o hardware do consumidor é incrivelmente limitado, portanto a escolha do algoritmo fica reduzida a apenas alguns… Ou até mesmo nenhum.

Image
Project Z-Treme (2019, Homebrew) [13].
Essa engine abandonou o Z-sort em troca de particionamento binário de espaço (BSP), corrigindo os glitches.

O método do Sega Saturn é o que considero um caso “meio resolvido”. O VDP1 não implementa nenhuma função VSD: Ou você entrega a geometria a ele na ordem correta, ou recebe dele uma bagunça. Entretanto, a Sega tinha uma biblioteca gráfica chamada “SGL”, que implementava uma solução chamada Z-sort ou Algoritmo do Pintor [14] o qual faz a ordenação dos polígonos via software.

Essencialmente, o SGL aloca um buffer para ordenar os polígonos baseando-se na distância deles da câmera (do mais distante ao mais próximo), então envia os comandos de exibição para o VDP1 nessa ordem.

Um dos problemas do Z-sort com espaços 3D é que o seu valor de distância (Z-order) é aproximado, então podem haver glitches visuais. Por causa disso, os desenvolvedores podiam deixar o SGL pra lá e implementar seus próprios algoritmos.

Em artigos mais para a frente, você verá abordagens alternativas. Algumas ainda dependem de software, enquanto outras são aceleradas via hardware.

A questão da transparência

O Sega Saturn é capaz de desenhar gráficos semitransparentes, isto é, de misturar camadas sobrepostas de cores (blending) para criar a ilusão de que podemos ver através delas. Infelizmente, os VDPs não são tão coordenados como se esperaria, então esse efeito não funciona direito quando as camadas estão em VDPs diferentes.

Como alternativa, os jogos podem ativar a propriedade “mesh” numa textura. Com texturas em mesh, o VDP1 define as coordenadas X/Y da textura como “transparentes” (vazias). Isso torna possível misturar outras camadas usando os pixels transparentes. Curiosamente, o mesh aparecia borrado se o console estivesse conectado à TV usando o sinal de vídeo composto (o que era o padrão de antigamente, além do RF), o que resultava numa maneira acidental, porém efetiva de atingir a semitransparência [15].

Como você deve suspeitar, isso não era viável em alguns jogos. No fim das contas, esses não tinham opção além de deixar para lá a semitransparência. Alguns estúdios acharam métodos engenhosos, agora dê uma olhada nesses dois casos:

Daytona, da Sega (1993).
Sonic R, da Traveller’s Tales (1997).
Ambos os jogos mandam o VDP1 desenhar os objetos de primeiro plano e o cenário de fundo. Já o VDP2 renderiza a paisagem distante e as estatísticas de jogo à frente dos modelos 3D. Por consequência, os modelos do VDP1 que tiverem semitransparência não irão refratar a paisagem do VDP2, já que o VDP1 não está ciente dos frame buffers do VDP2.

Além do meu terrível gameplay, você irá reparar que o plano de fundo do primeiro jogo brota do nada (sem semitransparência), enquanto o segundo jogo não apenas conseguiu a semitransparência como também um efeito de fading: A Traveller’s Tales encontrou uma solução ao mudar os registros da “taxa de mistura” do VDP2 (usados para definir o canal alpha da textura), combinando isso com uma mudança nos níveis de iluminação à medida que o personagem se aproxima [16].


Áudio

O subsistema de som consiste em várias partes [17]:

A oportunidade

As novas capacidades de áudio significavam que os estúdios finalmente podiam gravar/produzir trilhas sonoras internamente, e colocá-las no jogo sem ter de criar novos arranjos (como acontecia com os sequenciadores limitados, ou com chips com métodos de sintetização restritos).

Isto foi possível graças a uma combinação de vários fatores:


Sistema Operacional

Assim que o usuário liga o console, o primeiro componente que inicia é o System Management & Peripheral Control (SMPC), um microcontrolador de 4 bits que cuida da inicialização dos chips ao redor (coisas como ligar os dois SH-2 e colocá-los em configuração de “master-slave”) [18].

Image
Versão japonesa.
Image
Versões europeia e americana.
O logo exibido após a animação de início.

Depois, o vetor de reconfiguração do SH-2 master é colocado em 0x00000000 [19], o que aponta para uma ROM interna que contém o Initial Program Loader (IPL). O programa executa as seguintes funções [20]:

  1. Finaliza a inicialização do hardware.
  2. Se houver um cartucho inserido e ele incluir um programa, ele segue a inicialização a partir dele.
  3. Se um cartão de “Video CD” estiver inserido, o inicializa.
  4. Se houver um disco inserido, verifica se ele é genuíno.
    • E enquanto isso, ele exibe a animação de início.
  5. Se o disco for genuíno, inicie o jogo.
  6. Se o disco não for genuíno ou se não houver disco inserido, execute o shell.

Shell interativo

Além de rodar jogos, o Saturn incluía um player de música chamado “Multiplayer”, do qual é possível abrir um gerenciador de saves.

Image
Shell interativa chamada “Multiplayer” ou “Audio CD Control Panel”.
Image
Gerenciador de memória. Move saves entre o cartucho e a memória interna.

Se um Video CD estiver inserido, o player pode reproduzir vídeo MPEG decodificado do próprio cartão.

Sem BIOS?

Ao contrário do PlayStation, cuja ROM continha uma BIOS, que acabava expondo APIs para uso dos desenvolvedores. A ROM do Saturn costuma ser chamada de “IPL”, possivelmente porque sua função principal é inicializar o jogo e executar a shell. Entretanto, esta ainda guardava algumas rotinas (chamadas serviços) para manipular o hardware (tal como gerenciar os dados salvos e controle de energia). Ele tem até um “semáforo”! (usado para sincronizar operações que envolvem múltiplos processadores ao mesmo tempo). Por isso, essa parte da ROM é chamada de System program.


Jogos

Jogos oficiais de Sega Saturn são carregados do leitor 2x CD-ROM. Sua mídia, o compact disc (CD), tem capacidade de 680 MB, e os jogos de Sega Saturn seguem o padrão ISO 9660 de armazenamento de dados [21]. Além disso, muitos jogos armazenam as faixas de áudio próximo às faixas de dados, para streaming de áudio descomprimido enquanto o jogo roda.

O Compact Disc (CD)

O CD é uma mídia ótica onde a informação é armazenada pela gravação de pits (sulcos) e lands (saliências) em sua superfície de policarbonato [22]. Uma luz infravermelha é irradiada do leitor e seu reflexo na superfície do CD é usada para ler a informação gravada.

O processo de converter informação digital (zeros e uns) em pits e lands e vice-versa não é simples de forma alguma, especialmente dado que os CDs precisam ser robustos o bastante para suportar os danos do dia a dia e o uso intenso, assim como confiáveis para se guardar qualquer tipo de dado sem medo de perda. Por isso, como parte de sua especificação, os dados são gravados usando-se o modelo Non-Return-to-Zero inverted (NRZi), em que o fluxo de bits será totalmente de zeros até que uma mudança de land para pit ou de pit para land seja detectada, à qual o número 1 será atribuído.

O design funciona bem até o leitor encontrar uma sequência de 1 (mudanças contínuas entre pit e land) ou longas sequências de 0 (pits ou lands constantes), durante as quais o sensor terá, respectivamente, dificuldades com a detecção ou com a sincronia. Assim, um modelo adicional é aplicado, chamado modulação Eight-to-Fourteen (ETF). Através dele, um punhado de zeros é colocado para preencher os intervalos entre as codificações, ajudando o sensor na leitura.

Ainda outros mecanismos de detecção de erros podem ser adicionados, mas estes estão além do escopo deste artigo. Se estiver interessado em saber mais, você pode checar uma apresentação de slides da RWTH Aachen University [23].

Desenvolvimento

No começo, a Sega não forneceu bibliotecas de software completas nem ferramentas de desenvolvimento (na verdade, a documentação inicial continha erros), então o único jeito de obter boa performance era por meio de uma grossa programação de base.

Posteriormente, a Sega lançou SDKs completos, kits de hardware e algumas bibliotecas para facilitar operações I/O e de gráficos. No geral, os jogos são escritos numa mistura de C e várias linguagens de montagem direcionadas a componentes individuais.

E/S

O gerenciamento de periféricos e do relógio de tempo real são também fornecidas pelo System Management & Peripheral Control (SMPC). O SMPC é controlado por comandos enviados pelos SH-2.

Métodos de expansão

Esse console agrupa um número considerável de conectores externos e interfaces que receberam não mais que uma meia dúzia de usos, quando muito.


Anti-pirataria & Homebrew

Em resposta à facilidade de se clonar um CD, o Saturn adicionou um sistema de proteção contra cópias (junto a uma trava de região) para controlar a distribuição de jogos.

A proteção contra cópia nos CDs é aplicada gravando-se dados especiais (chamados de “área do sistema”) fora do alcance de gravadores convencionais. O Saturn se recusa a inicializar o disco como um “disco de jogo” se os dados da área fora de alcance não forem encontrados ou forem inválidos. O leitor de disco também contém um processador SH-1 customizado que se comunica com o resto do console usando protocolos ocultos.

Vale mencionar que, já que os CDs do Saturn seguem a norma ISO 9660 (um padrão de sistema de arquivos para dados em CD), os PCs podem ler os discos de jogos sem problemas (mas, claro, não podem executar o jogo a não ser que usem um emulador).

Derrota

O método clássico usado para desligar a proteção contra cópias consistia em instalar um mod-chip capaz de enganar o leitor de CD quando um disco gravado era inserido. Havia também o truque de troca, em que se fazia hot-swapping com um disco genuíno, trocando-o por um disco gravado logo após o fim da verificação de proteção… Com o risco de se estragar o drive!

Com a virada do século, foram descobertos métodos alternativos e mais sofisticados de rodar código não autorizado. Por exemplo:


Isso é tudo pessoal

Image
Um Saturn japonês que adquiri para obter mais material para esse artigo. Ainda que os jogos em si sejam bons, foi graças à imensa biblioteca de homebrew do Saturn que eu fui capaz de entender as verdadeiras capacidades desse console.

Contribuir

Este artigo faz parte da série Arquitetura dos Consoles. Se você o achou interessante, por favor, considere fazer uma doação. A sua contribuição será usada para financiar a compra de ferramentas e recursos que me ajudarão a melhorar a qualidade dos artigos existentes e dos que estão por vir.

Donate with PayPal
Become a Patreon

Você também pode comprar a edição eBook em inglês. Eu trato os lucros como doações.

Image

Uma lista de ferramentas desejáveis e as mais recentes aquisições para este artigo são mantidas aqui:

Acquired tools used

Como alternativa, você pode ajudar sugerindo alterações e/ou adicionando traduções.


Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-saturn,
    url = {https://classic.copetti.org/writings/consoles/sega-saturn/},
    title = {Sega Saturn Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "Sega Saturn Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://classic.copetti.org/writings/consoles/sega-saturn/. [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.


Fontes / Continuar lendo

Anti-pirataria

Áudio

Processador

Jogos

Gráficos

Sistema Operacional

Fotografia