Arquitetura do PlayStation

Uma análise prática por Rodrigo Copetti

Traduzido por Walper

Edição clássica - Última atualização: 19 de janeiro de 2024

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


Sobre esta edição

A edição 'clássica' é uma alternativa à edição 'moderna'. Não requer Javascript, CSS de última geração ou HTML complicado para funcionar, o que a torna ideal para leitores que utilizam ferramentas de acessibilidade ou navegadores antigos. Por outro lado, usuários de eBook podem agora ver a 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 permitir que os leitores reportem erros ou proponham mudanças. Há também uma lista de leitura de suporte disponível para ajudar a entender os artigos. O autor também aceita doações para ajudar a melhorar a qualidade dos artigos existentes e dos próximos artigos.


Índice

  1. Imagens de suporte
  2. Uma breve introdução
  3. CPU
    1. As origens
      1. Um pouco de história
      2. A MIPS e a Sony
      3. A LSI e a encomenda
    2. O produto oferecido
    3. Assumindo o controle da CPU
    4. Complementando o núcleo
      1. Coprocessador de Controle de Sistema
      2. Geometry Transformation Engine
      3. Motion Decoder
    5. Unidades ausentes?
    6. Uma infinidade de atrasos
  4. Gráficos
    1. Organizando o conteúdo
    2. Desenhando a cena
      1. Comandos
      2. Abordagem de visibilidade
      3. Rasterização
      4. Shaders
      5. Texturas
      6. Etapas restantes
    3. Designs
    4. Brincando com a VRAM
    5. Segredos e limitações
      1. Modelos/texturas distorcidas
      2. Alegações contraditórias
      3. Gráficos pré-renderizados
    6. Saída de vídeo
  5. Áudio
    1. A era do streaming
  6. E/S
    1. Subsistema de CD
    2. Portas frontais
  7. Sistema Operacional
    1. BIOS/Kernel
    2. Processo de inicialização
  8. Jogos
    1. Ecossistema de desenvolvimento
  9. Anti-pirataria / Trava de região
    1. Derrota
    2. Retaliação
  10. Isso é tudo pessoal
  11. Copyright and permissions
  12. Fontes / Continuar lendo
  13. Contribuir

Imagens de suporte

Modelo

Image
O PlayStation original.
Lançado em 03/12/1994 no Japão, 09/09/1995 na América do Norte, 29/09/1995 na Europa.
Image
O PS One (revisão slim).
Lançado em 07/07/2000 no Japão, 19/09/2000 na América do Norte, 29/09/2000 na Europa.
Isso é o que se obtém após colocar tantos CI personalizados em um único componente.

Placa-mãe

Image
Placa-mãe
Exibindo o modelo "SCPH-1000".
Os chips restantes são mostrados na parte traseira.
Modelos posteriores incluíram SG-RAM em vez de VRAM e removeram a maioria das entradas/saídas externas de vídeo.
Image
Placa-mãe com partes importantes rotuladas

Diagrama

Image
Diagrama de arquitetura principal
A Unidade de Interface de Barramento também está conectada a portas especiais da GPU e da SPU.

Uma breve introdução

A Sony sabia que o hardware 3D poderia se tornar muito complicado para ser desenvolvido. Assim, seu console estreante manteve seu projeto simples e prático… Embora isso tivesse um custo!


CPU

Esta seção analisa o Sony CXD8530BQ, um dos dois grandes chips que o console possui. É o que hoje chamamos de “System-on-Chip” (SoC — Sistema-no-Chip, em tradução livre).

As origens

O processador principal é um daqueles “x projetado por y, com base em z e adquirido de forma secundária por w”, o que é um pouco denso para resumir em algumas frases. Então, por que não começamos com um pouco de contexto histórico?

Um pouco de história

Os primeiros anos da década de 90 foram marcados por uma mudança no destino de muitas CPUs populares. As CPUs de 8 bits, como a Z80 e a 6502, que antes eram líderes de mercado, já não estavam mais em destaque. O famoso 68000 da Motorola, juntamente com outros projetos de 16 bits que fizeram sucesso no final dos anos 80, tornaram-se candidatos à substituição. Mesmo nessa época, no mundo dos PCs, Tanenbaum, em seu debate celebrado com Torvalds, deu apenas mais cinco anos de vida para a arquitetura x86 da Intel no mercado doméstico.

À primeira vista, pode parecer que o desenvolvimento tecnológico atingiu um limite naquele momento. Mas, na realidade, havia uma nova onda de CPUs pouco conhecidas que faziam seu caminho para dispositivos populares. Muitos desses projetos tiveram origem na academia, e existiam para provar determinados conjuntos de ideias de concepção. Exemplos de CPUs da próxima geração incluídos neste ponto:

Todos esses processadores tinham algo em comum: seguiram a disciplina do Reduced Instruction Set Computer (RISC), que mudou radicalmente a maneira como estes chips precisavam ser projetados e programados. Uma regra das CPUs RISC ditava que uma única instrução não pode misturar operações de memória com operações de registrador, permitindo que projetistas de hardware simplifiquem o circuito que executa instruções… e, em seguida, aprimorem-no com técnicas de paralelismo.

A MIPS e a Sony

No final dos anos 80, os processadores MIPS se tornaram um tópico de conversa após serem adotados (e posteriormente adquiridos) pela Silicon Graphics Incorporated (SGI) para equipar seus equipamentos. A SGI foi uma inovação influente no mercado de gráficos de computador, especialmente com o desenvolvimento de pipelines de vértices acelerados por hardware, cuja tarefa era originalmente realizada por software (dentro da CPU).

Durante o desenvolvimento do PlayStation, a MIPS estava oferecendo os processadores da série R3000A. Tratava-se de máquinas de 32 bits e era parte de seu catálogo de baixo custo. Consequentemente, embora o R3000A não fizesse parte da linha principal (ao contrário do R4000, que outros escolheriam mais tarde), era um investimento atraente em termos de custo.

A Sony projetou seus chips de áudio e de gráficos internamente, mas ainda precisava de um chip principal que pudesse conduzir os dois. A CPU escolhida tinha que ser poderosa o suficiente para mostrar as impressionantes capacidades dos chips da Sony, mas também acessível para manter o console a um preço competitivo.

A LSI e a encomenda

Ao mesmo tempo, a LSI Logic (uma fabricante de semicondutores) estava fornecendo um programa “construa sua própria” CPU para empresas. Este serviço era chamado de CoreWare e permitia que os clientes construíssem seus próprios pacotes de CPU escolhendo uma série de blocos de circuito [1]. Parte da biblioteca da CoreWare incluía o bloco “CW33300”, um núcleo de CPU derivado do LSI LR33300, um chip de CPU genérico que a LSI também comercializava.

Agora, onde estou querendo chegar com isso? Ocorre que o LR33300 e o CW33300 da LSI são uma versão compatível ao nível binário da família MIPS R3000A. Suas arquiteturas diferem ligeiramente em algumas áreas, mas a interface de programação (ISA MIPS) permanece a mesma.

No final, a Sony contratou a LSI para construir seu pacote de CPU. Eles escolheram o CW33300, alteraram alguns bits e combinaram com outros blocos para formar o chip encontrado na placa-mãe do PlayStation.

O produto oferecido

O núcleo da CPU resultante opera a 33,87 MHz e possui:

Para fazer algo significativo, a Sony forneceu 2 MB de RAM para uso geral. Curiosamente, eles instalaram chips Extended Data Out (EDO) na placa-mãe. Esses chips são ligeiramente mais eficientes do que uma DRAM típica, obtendo menor latência.

Assumindo o controle da CPU

Em algum momento, qualquer subsistema (gráfico, áudio ou CD) exigirá grandes quantidades de dados em alta velocidade. No entanto, a CPU nem sempre conseguirá acompanhar a demanda.

Por esse motivo, o controlador de CD-ROM, MDEC, GPU, SPU e a porta paralela têm acesso a um controlador DMA exclusivo sempre que precisam. O DMA assume o controle do barramento principal e realiza uma transferência de dados. A taxa resultante é muito mais rápida do que se dependesse da CPU, embora ela ainda seja necessária para configurar uma transferência do DMA.

Além disso, tenha em mente que quando o DMA é ativado, a CPU não pode mais acessar o barramento principal. Isso significa que a CPU ficará ociosa a menos que tenha algo na Scratchpad para mantê-la ocupada!

Complementando o núcleo

Assim como outros processadores baseados no MIPS R3000, o CW33300 suporta configurações com até quatro coprocessadores, mas a Sony personalizou-o com três:

Coprocessador de Controle de Sistema

Identificado como “CP0”, o coprocessador de controle de sistema é um bloco comum encontrando em CPUs MIPS. Em sistemas baseados no R3000, como este, o CP0 controla como a cache é implementada. Assim, permitindo o acesso direto à cache de dados (na forma de “Scratchpad”) e à cache de instruções (usando o “isolamento de cache”). O coprocessador de controle também é responsável por lidar com as interrupções, exceções e pontos de parada, sendo este último útil durante a depuração.

Espera aí, os coprocessadores não deveriam apenas expandir as funções da CPU? Por que o CP0 está fortemente acoplado à CPU?

De fato, os núcleos R3000 dependem do coprocessador de controle de sistema para conseguir usar muitos componentes, mas se isso deve ser “legal” ou não, depende da interpretação da palavra “coprocessador”. Segundo a MIPS, um coprocessador não é estritamente uma parte opcional da CPU, ele também pode comandar o ambiente da CPU (cache, interrupções, etc.). Portanto, um coprocessador pode ser uma parte integrante do sistema. Isso é apenas algo a se ter em mente ao falar sobre sistemas relacionados ao MIPS.

Posteriormente, os sistemas baseados no R4000 incorporaram uma unidade de gerência de memória (MMU, do inglês Memory Management Unit) e um Translation Lookaside Buffer (TLB) neste bloco, aumentando assim suas capacidades e assumindo novos papéis.

Geometry Transformation Engine

A “CP2” ou Geometry Transformation Engine (GTE) é um processador matemático especial que acelera cálculos de vetores e matrizes.

Embora opere apenas com valores do tipo ponto fixo, ele ainda fornece operações úteis para gráficos 3D, como:

Você não precisa se lembrar de todas essas informações para seguir o restante do artigo! Apenas tenha em mente que o GTE cuidará das primeiras etapas do pipeline de gráficos, como projeção 3D, iluminação e recorte. Isso ajudará a gerar os dados necessários que serão enviados à GPU para renderização.

Motion Decoder

O Motion Decoder (decodificador de movimento, em tradução livre), também é chamado “MDEC” ou “Macroblock Decoder”, é outro processador que fica ao lado da CPU. Desta vez, ele descomprime “Macroblocks” em um formato que a GPU consegue entender. Um Macroblock é uma estrutura de dados que contém uma imagem com codificação semelhante à do JPEG.

O MDEC descomprime por vez bitmaps feitos de 8x8 píxeis com 24 bpp. O guia de programação de Walker afirma que o MDEC pode processar 9.000 macroblocks por segundo. Isso permitiria transmitir um Full-Motion Video (FMV — vídeo de movimento completo, em tradução livre) de 320x240 píxeis a 30 quadros por segundo.

O DMA é usado para enviar dados comprimidos através do CD-ROM → RAM → MDEC. O mesmo caminho é percorrido na direção oposta, embora, neste caso, o destino seja a VRAM.

Embora este componente esteja dentro do SoC e compartilhe o mesmo barramento de dados, ele não é um coprocessador MIPS, então a CPU/DMA o acessa através do mapa de memória (em vez de interceptar instruções).

Para obter mais informações sobre a unidade MDEC, sugiro verificar os textos de Sabin [3] e de Czekański’s [4].

Unidades ausentes?

Até agora, temos uma “CP0” e uma “CP2”, mas onde está a “CP1”? Bem, essa está reservada para uma Unidade de Ponto Flutuante (FPU) e, infelizmente, a Sony não forneceu uma. Isso não significa que a CPU não possa realizar aritmética com números decimais, apenas não será rápida o suficiente (usando FPU emulada por software) ou muito precisa (usando aritmética de ponto fixo).

A lógica do jogo (envolvendo física, detecção de colisão, etc.) ainda pode funcionar com aritmética de ponto fixo. A codificação de ponto fixo armazena números decimais com um número imutável de casas decimais. Isso implica uma perda de precisão após certas operações, mas lembre-se, isso é um console de videogame, não um simulador de voo profissional. Portanto, o trade-off entre precisão e desemprenho é relativamente viável.

Aliás, às vezes confundo os tipos de números “ponto fixo”, “ponto flutuante”, “decimal” e “inteiro” (espero que não mais!). Se você se sente da mesma forma, recomendo dar uma olhada no resumo rápido de Gabriel Ivancescu [5] para atualizar rapidamente esses conceitos.

Uma infinidade de atrasos

Como já vimos anteriormente, o processador CW33300 é um processador com pipeline, o que significa que ele coloca várias instruções em fila e as executa em paralelo em diferentes estágios. Isso melhora enormemente a taxa de processamento de instruções, mas se não for controlado adequadamente, pode levar a riscos de pipeline (pipeline hazards), resultando em erros computacionais.

A arquitetura MIPS I é suscetível a riscos de controle e de dados [6], o que significa que as instruções podem ser executadas quando não deveriam; e que as instruções podem operar com dados desatualizados antes de serem atualizados.

Image
Instruções de “Spyro The Dragon” visualizada no depurador do emulador NO$PSX. Observe como as instruções LW (load word from memory), JAL (jump and link) e BAL (branch on not equal) são seguidas por um slot de atraso para evitar os riscos de pipeline. As instruções marcadas em vermelho são de preenchimento sem utilidade. As instruções marcadas em azul executam operações úteis.

Consequentemente, as CPUs MIPS I apresentam o seguinte comportamento:

Como podemos ver a partir do exemplo, alguns slots de atraso são preenchidos com instruções úteis, que realizam cálculos que não são afetados pelo risco de pipeline. Assim, os slots de atraso nem sempre implicam em desperdício de ciclos.

Geralmente, o compilador ou montador automaticamente reorganizará as instruções para preencher os slots com instruções úteis, ou, em último caso, adicionará preenchimentos inúteis. Em resumo, esse fenômeno é uma mistura de coisas boas e ruins.


Gráficos

Recapitulando, uma grande parte do pipeline gráfico é realizado pelo GTE. Isso inclui a transformação de perspectiva (que projeta o espaço 3D em um plano 2D usando a perspectiva da câmera) e a iluminação. Os dados processados são então enviados para a GPU proprietária da Sony para renderização.

Organizando o conteúdo

O sistema possui 1 MB de VRAM que é usada para armazenar o buffer de imagem (do inglês, frame buffer), texturas e outros recursos que a GPU precisa para renderizar uma cena. A CPU pode preencher essa área usando o DMA.

O tipo de chip utilizado (VRAM) é de duas portas, como no Virtual Boy. A VRAM utiliza dois barramentos de 16 bits, o que possibilita o acesso simultâneo entre a CPU/DMA/GPU e o codificador de vídeo.

Image
Layout de memória usando VRAM.
Image
Layout de memória usando SGRAM.

Embora em revisões posteriores do console, a Sony tenha mudado para chips SGRAM (a opção de porta única usando um barramento de dados de 32 bits individuais). Que pena!… Bem, para ser justo, cada um tem suas vantagens e desvantagens. Uma coisa é certa, devido às diferenças de temporização, jogos posteriores (como Jet Moto 3) exibirão gráficos com falhas quando executados nos sistemas baseados em VRAM. Se você quiser saber os detalhes, o documento “Nocash PSX Specifications” de Martin Korth descreve as diferentes temporizações e outras especificações [7].

Desenhando a cena

Se você leu o artigo sobre o Sega Saturn, deixe-me dizer que o projeto desta GPU é muito mais simples!

Agora, para mostrar como uma cena é desenhada, vou usar principalmente como exemplo o jogo Spyro: Year of the Dragon da Isomniac. Por favor, tenha em mente que a resolução interna deste jogo é muito baixa (292x217 píxeis), o que impede uma análise clara de cada estágio, então eu aumentei um pouco a escala para fins de demonstração. Aqui é uma amostra na escala original se você estiver curioso.

Comandos

Image
Pipeline básico de comandos da GPU.

Para começar, a CPU envia dados de geometria (vértices) para a GPU preenchendo seu buffer FIFO interno de 64 bytes com comandos (até três). Basicamente, um comando declara como e onde desenhar uma primitiva.

Uma vez que a geometria é recebida, é aplicado o recorte para evitar operações nos polígonos não vistos (localizados fora do campo de visão da câmera).

A localização da primitiva é declarada com um sistema de coordenada X, Y apontando para o buffer de imagem. A GPU do PS1 emprega um modelo de coordenadas inteiras, onde cada coordenada corresponde ao ponto central de um píxel (chamado de ponto de amostragem). Em outras palavras, não há coordenadas fracionárias.

Abordagem de visibilidade

Image
Crash Bandicoot (1996). Este jogo usava geometria pré-ordenada para ganhar desempenho [8]. Portanto, sua câmera só se move para trás ou para frente.

Assim como a concorrência, o PS1 não inclui nenhuma funcionalidade de hardware que resolva o problema de visibilidade. No entanto, a GPU lida com polígonos ordenados fornecendo uma tabela de ordenação: uma tabela dedicada onde cada entrada é indexada usando um valor de profundidade (também chamado de “valor Z”) e contém o endereço onde fica o comando da GPU [9].

A CPU precisa primeiro ordenar manualmente os polígonos e, em seguida, referenciá-los na entrada correta da tabela. Finalmente, a CPU ordena que o DMA envie a tabela para a GPU. Esse processo permite que a GPU renderize a geometria na ordem correta.

O DMA também oferece diversas funções para auxiliar tanto a CPU quanto a GPU na criação e transferência dessa tabela.

Rasterização

Image
Visualização do wireframe da cena.

Uma vez que os comandos são decodificados pela GPU, é hora de converter a geometria recebida (vértices) em píxeis. Isso permite que o sistema aplique o mapeamento de textura, efeitos e, por fim, exiba-os em um painel de duas dimensões (sua TV ou seu monitor). Para fazer isso, a GPU aloca uma matriz de píxeis que é usada como uma área de trabalho, chamada de buffer de imagem. Comparado com o complexo Sega Saturn, a GPU só precisa de um único buffer de imagem.

A GPU usa triângulos como primitivas para formar os modelos 3D. Ao ser a única primitiva disponível, as diferenças entre plano de fundo e elementos em primeiro plano não fazem diferença em termos de composição (ambos são constituídos por triângulos). Jogos em 2D herdam a mesma natureza: eles são apenas dois triângulos unidos para formar um quadrilátero (embora a GPU forneça rotinas para construir sprites automaticamente).

O rasterizador é a unidade responsável por converter vetores em triângulos e, em seguida, em píxeis. Isso é feito por meio de:

  1. Capturando cada vértice de três pontos e calculando as arestas. Isso forma um triângulo.
  2. Analisando a área do triângulo para identificar quais píxeis do buffer de imagem eles ocupam. Qualquer seção do triângulo que cobre o ponto de amostragem é convertida em um píxel.

Os píxeis gerados não são escritos imediatamente no buffer de imagem. Em vez disso, eles são enviados para os próximos estágios do pipeline para processamento adicional, que veremos nos parágrafos seguintes.

Shaders

Image
Gouraud shading em ação.

Para aplicar efeitos de iluminação sobre esses polígonos, a GPU fornece dois algoritmos:

A razão para ter essa escolha se resume ao fato de que o flat shading preenche cerca de 2,5 vezes mais polígonos por segundo do que o Gouraud, portanto, é importante otimizar quais polígonos precisam de um sombreamento mais realista do que outros.

Texturas

Image
Texturas aplicadas (Tada!).

Finalmente, superfícies sombreadas são mescladas com as texturas (bitmaps 2D) para produzir o resultado final.

A GPU realiza o mapeamento de textura inversa, onde a GPU percorre cada píxel rasterizado e procura o píxel correspondente no mapa de textura (chamado de textel). Os texels são calculados interpolando linearmente o mapa de textura (encontrado na VRAM) para ajustar ao formato do polígono. A rotina usada para a interpolação é chamada de mapeamento de textura afim, essa técnica opera apenas usando coordenadas 2D (valores de X e Y) enquanto descarta a terceira coordenada (Z ou profundidade) usada para perspectiva.

Devido os mapas de textura raramente terem a dimensão exata do polígono rasterizado, os serrilhados (resultados incorretos) podem aparecer. Isso se manifesta com distorções indesejadas, como texels faltantes ou ampliados. Para remediar isso, GPUs sofisticadas empregam filtragem de textura para suavizar (interpolando) mudanças repentinas de cor. Agora, a GPU do PS1 não implementa nenhum filtro, então ele recorre a um algoritmo chamado vizinho mais próximo para corrigir escalas sem suavizar os resultados. Isso é muito rápido (e barato), mas também explica porque os modelos texturizados podem parecer “quadriculados”.

A unidade gráfica também inclui os seguintes efeitos disponíveis para uso:

Vale ressaltar que o PS1 se destacou na realização desses efeitos!

Etapas restantes

Uma vez finalizado, a GPU escreve os píxeis no buffer de imagem na VRAM, que, por sua vez, são capturados pelo codificador de vídeo e transmitidos para a tela.

Designs

Vamos dar uma pausa agora em toda essa teoria. Aqui estão alguns exemplos de personagens de jogos projetados do zero para a era 3D, eles são interativos, então eu encorajo você a conferi-los!

Image Image Image Modelo interativo disponível na edição moderna
Spyro the Dragon (1998).
413 trângulos.
Image Image Image Modelo interativo disponível na edição moderna
Crash Bandicoot (1996).
732 triângulos.

Brincando com a VRAM

Com a quantidade disponível de VRAM (1 megabyte inteiro), pode-se alocar um enorme buffer de imagem de 1024x512 píxeis com cores de 16 bits ou um realista de 960x512 píxeis com cores de 24 bits — permitindo desenhar os melhores quadros que qualquer jogo já mostrou… Isso parece bastante impressionante, certo? Bem, isso levanta algumas questões, por exemplo:

Tudo bem, então vamos ter um buffer de 640x480 com 16 bpp, o que deixa 424 KB de VRAM para recursos visuais. Até agora tudo bem? Novamente, tal resolução pode ser boa em monitores CRT, mas não particularmente notável naquelas TVs dos anos 90 que todo mundo tinha em casa. Então, há alguma maneira de otimizar o buffer de imagem? Apresentando o buffer de imagem ajustável.

Image
Visualização da VRAM no depurador NO$PSX. Você pode ver o buffer de dois quadros de imagem, juntamente com as texturas (que são traduzidas usando uma tabela de cores, também armazenadas ali).

Em essência, em vez de desperdiçar a valiosa VRAM usando resoluções “não apreciadas”, a GPU permite diminuir as dimensões do buffer de imagem para aumentar efetivamente o espaço disponível para outros recursos. Em “Gears Episode 2” [10], Halkun mostra uma configuração que divide o buffer de imagem de 640x480 em dois de 320x480 e, em seguida, confia em uma técnica chamada de page-flipping (alternância de página, em tradução livre) para renderizar várias cenas simultaneamente.

O page-flipping consiste em alternar a localização do quadro para exibição entre os dois disponíveis sempre que o jogo quiser, permitindo que o jogo renderize uma cena enquanto exibe outra. Assim, escondendo qualquer efeito de cintilação e melhorando os tempos de carregamento (algo que certamente o jogador apreciará!).

No geral, o layout de Halkun consome apenas 600 KB de VRAM. O resto (424 KB) pode ser usado para armazenar tabelas de consulta de cores e texturas que, combinadas com 2 KB de cache de textura disponível, resultam em uma configuração muito conveniente e eficiente.

Finalmente, vale mencionar que a VRAM pode ser mapeada usando várias profundidades de cor simultaneamente, o que significa que os programadores podem alocar um buffer de imagem de 16 bpp ao lado de bitmaps de 24 bpp (usados, por exemplo, em quadros de FMV). Essa é outra característica que facilita ainda mais a otimização do espaço.

Segredos e limitações

Embora o PS1 tivesse uma arquitetura muito simples e adequada, surgiram problemas de qualquer maneira. Surpreendentemente, certos probelmas foram resolvidos com soluções inteligentes e engenhosas!

Modelos/texturas distorcidas

Final Fantasy VIII da Square Soft (1999). As texturas tremem um pouco enquanto se movem.

As rotinas usadas para manipulação de geometria e aplicação de textura são conhecidas por apresentar algumas imprecisões.

Em primeiro lugar, o rasterizador só manipula unidades de píxeis: enquanto as coordenadas dos vértices são inteiras, as bordas do triângulo calculadas podem ocupar apenas uma fração do píxel. No entanto, o rasterizador só desenhará o píxel se a área do triângulo cobrir o ponto de amostragem do píxel e não acompanhará a fração ocupada [11]. Isso traz alguns problemas:

Isso é comumente resolvido implementando a resolução subpíxel, onde o rasterizador acompanha as frações de píxeis ocupados por cada área do triângulo [12]. Consequentemente, métodos de antisserrilhamento podem ser adicionados para suavizar bordas irregulares ou mudanças abruptas na cor.

Além disso, a tabela de ordenação coloca a responsabilidade no desenvolvedor/programador para mostrar a geometria na ordem correta. Em alguns casos, os cálculos implementados dependem de muitas aproximações para ganhar desempenho. Isso pode resultar em superfícies piscando ou ocultas que deveriam ter sido exibidas.

Além disso, definir um buffer de imagem de baixa resolução pode amplificar todos esses problemas de serrilhamento.

Finalmente, como você sabe, as transformações afins não têm noção de profundidade, o que pode confundir a percepção do usuário quando a câmera está próxima do modelo e posicionada perpendicularmente ao espectador [13]. O efeito é referido como distorção de textura. Por isso, alguns jogos recorreram à tesselação (dividindo um polígono grande em polígonos menores) para reduzir a distorção, enquanto outros simplesmente trocaram as texturas por cores sólidas. Em geral, uma GPU resolve esse problema implementando a correção de perspectiva, que interpola as texturas usando o valor de profundidade.

Alegações contraditórias

Se você verificar outros canais técnicos ou fóruns, encontrará explicações alternativas sobre os efeitos de oscilação e distorção do PS1. Embora alguns deles coincidam com o que expliquei anteriormente, outros argumentarão de forma diferente. Portanto, gostaria de dar minha opinião sobre o por que as seguintes declarações não são precisas:

Modelos e texturas oscilam devido à falta de FPU

Um FPU não dita se um computador pode operar ou não com números fracionários. O PS1, como qualquer outro computador sem uma FPU, ainda pode realizar aritmética de ponto fixo. Além disso, usando emulação de software, números de ponto flutuante também podem ser calculados (apenas mais lentamente). Em resumo, as FPUs são apenas aceleradores, não os confunda com uma ALU (a parte crítica de uma CPU que realiza aritmética) ou números decimais.

Modelos e texturas tremem devido ao sistema de coordenadas inteiras da GPU

Usar coordenadas inteiras é uma abordagem comum para tornar os cálculos menos dispendiosos na GPU. É o fato de não usar a resolução de subpíxeis que torna isso em um problema visível. Resumindo, o antisserrilhamento poderia ser aplicado para suavizar mudanças abruptas de cores se o rasterizador contasse a fração do píxel ocupada pelo triângulo.

Texturas sofrem deformação devido à falta de mipmapping (mapa de níveis de detalhe, em tradução livre)

As GPUs que implementam o mapeamento de textura inverso, como esta, estão sujeitas a um erro de medição chamado de “subamostragem” (um píxel é mapeado para vários texels). Isso cria serrilhamentos (resultados incorretos). Esse comportamento é percebido ao renderizar geometrias distantes da câmera. Para remediar isso, os mapeadores modernos de textura aplicam um “filtro trilinear”, que suaviza os texels usando a mesma textura armazenada em diferentes escalas (mipmaps) e faz alguma interpolação no meio. Em resumo, o mipmapping é uma abordagem para resolver os serrilhamentos. É o mapeamento de textura afim (com sua falta de correção de perspectiva) que interpola texturas em superfícies de três pontos sem considerar a profundidade. Daí o efeito de “deformação”.

Modelos ou texturas tremulam devido à falta de buffer de profundidade

Uma GPU com buffer de profundidade resolve o problema da determinação de superfícies visíveis ao nível de hardware. O PS1 depende de uma tabela de ordenação, o que significa que os desenvolvedores são responsáveis por determinar qual geometria está à frente das outras. Em resumo, qualquer modelo exibindo triângulos tremulantes é causado pelas rotinas de ordenação (software), portanto, é remediado no mesmo software.

Gráficos pré-renderizados

Image
Final Fantasy VIII da Square Soft (1999). Uma cena com plano de fundo pré-renderizado. A maneira como os modelos interagem e se movem é essencial para enganar a percepção do usuário.

Vamos mencionar uma funcionalidade “positiva” para variar…

Se um jogo procurava uma paisagem mais realista do que o que a GPU podia oferecer, uma opção disponível era empilhar dois triângulos e usar o Motion Decoder para reproduzir animação pré-renderizada neles. Vídeos FMV podiam ter um tamanho muito grande, e felizmente o CD-ROM estava preparado para isso.

Alguns jogos contavam especificamente com essa técnica para compor fundos e, honestamente, era bastante convincente vê-los em uma TV CRT, obviamente os emuladores modernos com capacidade de aumento de resolução revelam isso muito facilmente.

Saída de vídeo

A primeira revisão do console apresenta uma quantidade surpreendente de sinais de vídeo com as seguintes portas:

Revisões posteriores do console removeram essas portas e, no final, apenas a porta “AV Multi Out” permaneceu.


Áudio

A unidade de processamento de som (SPU, do inglês Sound Processing Unit) cuida disso. Este chip suporta a enorme quantidade de 24 canais de amostras de 16 bits ADPCM (uma versão mais eficiente da, já conhecida, amostragem PCM) com uma taxa de amostragem de 44,1 kHz (qualidade de áudio de CD).

Este chip também oferece as seguintes capacidades:

512 KB de DRAM (chamada de “RAM de som”) são fornecidos como buffer de áudio. Esta memória é acessível a partir da CPU (somente através do DMA) e do controlador de CD. Embora os jogos tenham apenas 508 KB disponíveis para armazenar amostras, o restante é reservado pela SPU para processar música de CD de áudio. Essa quantidade é reduzida ainda mais se a reverberação estiver ativada.

O controlador de CD também pode enviar amostras diretamente para o mixer de áudio sem passar pelo buffer de áudio ou exigir intervenção da CPU. As amostras também podem ser comprimidas usando a codificação “XA”, que a SPU consegue decodificar em tempo real.

A era do streaming

Assim como no Saturn, os jogos não dependem mais do sequenciamento de música ou de formas de onda pré-definidas, e graças à quantidade de espaço disponível na mídia CD-ROM, os desenvolvedores podem armazenar amostras totalmente produzidas e simplesmente transmiti-las para o chip de áudio.


E/S

Existem duas portas de E/S (Serial e Paralela) disponíveis para expensão. Contudo, elas foram removidas em revisões posteriores do console devido à falta de adoção e ao fato de que elas poderiam ser potencialmente usadas para quebrar o sistema de proteção contra pirataria.

Subsistema de CD

O bloco que controla a unidade de CD é uma área interessante, você pode imaginá-lo como um computador separado vivendo dentro do PlayStation.

Image
Layout do subsistema de CD.

Este subsistema é composto de:

O subsistema se assemelha um pouco a um leitor de CD típico que todos tinham em casa, exceto pelos ajustes que a Sony implementou no programa da Sub-CPU para realizar verificações contra pirataria.

Portas frontais

O controle e os slots do memory card são eletricamente idênticos [15], portanto, o endereço de cada um deles é codificado diretamente no hardware. Além disso, a Sony alterou a forma física das portas para evitar acidentes.

A comunicação com esses dispositivos é feita usando uma interface serial. Os comandos enviados pelo console serão entregues a um dos dois slots (ou “mem. card 0” e “controle 0”, ou “mem. card 1” e “controle 1”). Em seguida, ambos os acessórios responderão com seus identificadores exclusivos, permitindo que o console se concentre em um tipo específico de dispositivo (memory card ou controle) daquele momento em diante.


Sistema Operacional

O sistema inclui uma ROM de 512 KB que armazena uma “BIOS”. Este programa realiza muitos serviços, incluindo cuidar do processo de inicialização, exibir uma interface de usuário (shell) e, finalmente, expor uma coleção de rotinas de E/S [16].

BIOS/Kernel

A BIOS é uma dependência crítica para os jogos, pois esse programa os inicia a partir da unidade de CD. Além disso, a BIOS funciona como um “intermediário” para interagir com o hardware do console. A metodologia anterior é semelhante ao que a IBM implementou com sua BIOS do IBM PC, que incentivou os desenvolvedores a usar uma tabela padrão de interrupção (contendo rotinas de E/S) em vez de portas de E/S dependentes da plataforma.

Dito isso, a BIOS do PS1 disponibiliza rotinas como:

Como o acesso à ROM da BIOS é muito lento (está conectado a um barramento de dados de 8 bits), as APIs são empacotadas na forma de um Kernel e copiadas para a RAM principal durante a inicialização. Assim, 64 KB da RAM principal são reservados para esse Kernel. Aliás, o Kernel também é referido como PlayStation OS.

Processo de inicialização

O vetor de inicialização da CPU está localizado no endereço 0xBFC00000, o qual aponta para a ROM da BIOS.

Image
Famosa cena de abertura após ligar o console.
Image
Logo do PlayStation mostrado após um jogo original ser inserido.
Image
A shell é exibida se não houver nenhum disco inserido.

Da mesma forma que o processo de inicialização do Saturn, depois de receber energia, o PS1 irá:

  1. Buscar a ROM da BIOS e executar rotinas para inicializar o hardware.
  2. Carregar o PlayStation OS.
  3. Exibir a tela de carregamento.
  4. Se houver um CD inserido, o controlador de CD-ROM verificará se é original:
    • É original → o controlador permitirá a leitura de seu conteúdo.
      1. A CPU procurará pelo arquivo “SYSTEM.CNF” e continuará a execução a partir daí.
    • Não é original → A CPU exibirá uma mensagem de erro.
  5. Sem CD inserido, a CPU exibirá uma shell. O usuário agora tem o controle.

A shell é uma interface gráfica simples que permite ao usuário copiar ou excluir salvamentos do memory card; ou reproduzir um CD de áudio.


Jogos

Assim como o Sega Saturn e qualquer outro console que fez a transição para a mídia de CD, os jogos agora têm um novo conjunto de recursos: grande armazenamento (640 MB), qualidade de áudio boa e uma velocidade de leitura “não tão lenta” graças as unidades de velocidade dupla.

Se você quiser saber como o Disco Compacto (CD) funciona, eu escrevi uma explicação rápida no artigo do Sega Saturn.

Ecossistema de desenvolvimento

O SDK oficial forneceu bibliotecas em C que estão vinculadas às rotinas da BIOS para acessar o hardware. Caso esteja se perguntando, esse é o principal fator que ajudou a emular o PS1 em uma ampla gama de plataformas.

Junto com o SDK, a Sony também distribuiu hardware especializado, como o DTL-H2000: um cartão ISA de dois slots contendo as partes internas e de E/S do PS1 [17], além de circuitos extras para fins de depuração. A placa tem acesso ao disco rígido do computador hospedeiro e pode executar software do PS1 sem restrições. O respectivo software exigia um PC com Windows 3.1 ou 95 instalado.


Anti-pirataria / Trava de região

Como você deve saber, para recuperar dados de um CD, um feixe de laser é usado para detectar as cavidades e as áreas refletoras da trilha do disco.

Agora, discos convencionais não são 100% planos e frequentemente têm pequenas flutuações em suas trilhas. Esses defeitos são completamente imperceptíveis durante a leitura dos dados, uma vez que os lasers podem se calibrar automaticamente conforme eles leem.

Foi com base nisso que a Sony desenvolveu sua proteção contra cópias: a Sub-CPU permite a leitura de discos cujas tabelas de conteúdo (TOC, do inglês Table of Contents) foram gravadas usando uma frequência definida informalmente conhecida como Wobble Groove (ranhura de oscilação, em tradução livre), que é aplicada apenas durante a fabricação e não pode ser replicada por gravadores convencionais. A TOC é encontrada na seção interna do CD (chamada de “Lead-In” — trilha de início, em tradução livre) e instrui o laser sobre como navegar pelo disco [18]. Além disso, ela é repetida muitas vezes como um mecanismo de tolerância a falhas.

Dentro da TOC dos jogos do PS1, é incorporada uma das seguintes sequências de caracteres:

Como você pode imaginar, o leitor aplica a trava de região usando esta técnica também.

Derrota

Por outro lado, essa verificação é executada apenas uma vez no início, então trocar manualmente o disco logo após passar pela verificação pode derrotar essa proteção… com o risco de danificar a unidade de CD. Mais tarde, alguns jogos tomaram medidas próprias e frequentemente reiniciaram a unidade de CD durante o jogo para que a verificação fosse executada novamente, isso foi feito para impedir que os usuários realizassem o “truque da troca”.

Alternativamente, pequenas placas programadas para imitar o sinal de wobble podiam ser soldadas no console. Essas placas são conhecidas como Modchips e, embora questionáveis legalmente, eram incrivelmente populares.

Retaliação

O uso de emuladores também foi visto como uma ameaça pelas publicadoras de jogos. Como resultado, alguns jogos incluíram seus próprios controles (principalmente checksums — verificação de integridade, em tradução livre) para combater qualquer tipo de uso ou modificação não autorizada.

Um dos controles que me foi informado consistia em reinicializar deliberadamente a unidade de CD e, em seguida, fazer com que ele lesse setores específicos que não passariam na verificação do wobble groove. Se conseguissem desbloquear a unidade de CD de alguma forma, o jogo (ainda residente na RAM) revelaria alegremente seu material anti-pirataria. Note que essa abordagem também pode afetar consoles modificados que usam jogos originais.

Mais tarde, a Sony forneceu uma biblioteca chamada Lybcrypt que fortaleceu a proteção contra pirataria com o uso de duas abordagens [19]:


Isso é tudo pessoal


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:

Interesting hardware to get (ordered by priority)

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-ps1,
    url = {https://classic.copetti.org/writings/consoles/playstation/},
    title = {PlayStation Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "PlayStation Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://classic.copetti.org/writings/consoles/playstation/. [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

Proteção contra cópia

Processador

Jogos

Gráficos

E/S

Sistema Operacional

Outras Mídias

Fotografia