Arquitetura do Super Nintendo

Depois de tudo o que foi dito até agora, deixe-me dizer que o subsistema gráfico deste console é um verdadeiro trabalho de engenharia. Com uma CPU tão limitada, alguém poderia imaginar que o SNES nunca poderia competir com seu concorrente, o Motorola 68000 com seus "32 bits". No entanto, os engenheiros da Nintendo e da Ricoh conseguiram encontrar truques inteligentes que tiram proveito da forma como os monitores CRT se comportam, expandindo assim as capacidades do console sem exigir componentes caros de última geração.

De qualquer forma, antes de aprofundarmos, recomendo fortemente que você leia primeiro artigo sobre o NES, pois ele apresenta conceitos úteis que serão revisitados aqui.

Projeto

Como qualquer outro console de sua geração, o Super Nintendo desenha gráficos usando tiles 2D (8 x 8 píxeis). O NES originalmente realizava isso agrupando a "Unidade de Processamento de Imagem" (PPU, do inglês * Picture Processing Unit*) que projetava a imagem em sincronia com uma tela CRT. O Super Nintendo segue o mesmo caminho, mas agora implementa técnicas mais sofisticadas para obter resultados mais ricos.

O chipset

O Super Nintendo possui dois chips PPU diferentes que constituem o subsistema gráfico, os quais combinados são conhecidos como Super PPU ou "S-PPU". Ambos os pacotes PPU são projetados para servir diferentes funcionalidades :

• PPU 1: renderiza gráficos (tiles) e aplica transformações neles (rotação e dimensionamento).
• PPU 2: fornece efeitos como janela, mosaico e desvanecimentos sobre os gráficos renderizados.

Essa separação, do ponto de vista da programação, é redundante, dado que ambos os chips são virtualmente tratados como um só.

Modalidades de exibição

O sistema produz uma resolução padrão de 256 x 224 píxeis a ~60 Hz (NTSC) . A versão europeia PAL produz uma resolução de 256 x 240 píxeis a ~50 Hz em vez disso (para atender à especificação PAL). Seja como for, a maioria dos jogos não utiliza os píxeis extras e exibe faixas pretas em cima e embaixo da tela.

Aqui está a parte complicada: as TVs tradicionais têm uma proporção de aspecto de 4:3. No entanto, se fizermos as contas, a resolução de saída do Super Nintendo tem a proporção de aspecto de 8:7. Consequentemente, após projetarr a imagem na TV, ela parecerá esticada horizontalmente, como se fosse um quadro de 292 x 224 píxeis (no caso da versão NTSC) . Em outras palavras, poderíamos dizer que os píxeis no Super Nintendo têm uma proporção de aspecto de 8:7 em vez de serem "perfeitamente quadrados".

Quadro renderizado com a resolução de 256 x 224 píxeis. É assim o quadro que o console envia para a TV.

Quadro esticado como visto na TV (com uma resolução aparente de 292 x 224 píxeis).

Alguns jogos, como "The Legend of Zelda: A Link to the Past", considera esse fator, de modo que as formas são explicitamente projetadas achatadas, o que parece correto após serem esticadas pela TV. Isso, no entanto, é um caso excepcional, já que a maioria dos jogos não toma medidas extras para lidar com esse fator.

Organizando o conteúdo

Arquitetura de memória da S-PPU.

Por motivos de custos e desempenho, os dados gráficos são distribuídos em três regiões de memória:

• 64 KB de VRAM (Video RAM): armazena tiles e mapas (tabelas) usados para construir camadas de plano de fundo (background).
• 512 B de CGRAM (* Colour Graphics RAM): contém 512 entradas de paleta de cores, cada entrada tem o tamanho de uma palavra* (16 bits).
• 544 B de OAM (Object Attribute Memory): contém tabelas com referência de 128 tiles que serão usados como sprites, juntamente com seus atributos.

Construindo o quadro (frame)

Vamos agora ver como um quadro é renderizado no console e posteriormente exibido na TV. Para fins de demonstração, Super Mario World é usado como exemplo.

Tiles

Alguns Tiles de 16x16 encontrado na VRAM.

Assim como seu antecessor, o S-PPU usa tiles para construir gráficos sofisticados. Embora haja melhorias significativas em comparação ao PPU original:

• Os cartuchos de jogos não estão mais conectados a PPU, portanto, os tiles terão que ser copiados para a VRAM primeiro (assim como no Mega Drive da Sega). É aí que a unidade DMA se torna muito útil.
• Os Tiles não estão mais restritos a sua dimensão (8x8 píxeis), a partir de agora eles também podem ter tamanho de 16x16 píxeis.
• Quando os tiles são armazenados na memória, eles são comprimidos dependendo de quantas cores por píxel precisam ser usadas. A unidade de tamanho é bpp (bits por píxel). O valor mínimo é de 2 bpp (onde cada píxel ocupa apenas dois bits na memória e tem apenas 4 cores disponíveis) enquanto o máximo é 8 bpp, que codifica até 256 cores (com o custo de consumir um byte inteiro).

Plano de fundo

Camada de plano de fundo 1 (BG1).

Camada de plano de fundo 2 (BG2).

Camada de plano de fundo 3 (BG3).

Camada de plano de fundo renderizada (BG1).

Camada de plano de fundo renderizada (BG2).

Camada de plano de fundo renderizada (BG3).

Camadas de plano de fundo renderizadas combinadas.

O Super Nintendo pode gerar até quatro planos de fundo diferentes. Usando tiles de 8x8 ou 16x16, os blocos são feitos de 32x32 píxeis (tiles de 2x2). Dito isso, o tamanho de cada camada de fundo pode ser de até 1024x1024 píxeis de tamanho (32x32 tiles). A região na VRAM onde essas camadas são configuradas é chamada de Tilemap e é estruturada como uma tabela (valores contínuos na memória).

Cada entrada no Tilemap contém os seguintes atributos:

• Valores de flip vertical e horizontal.
• Prioridade (0 ou 1).
• Referência da paleta na CRAM.
• Referência de tile.

Como sempre, esses planos são roláveis, embora o número de recursos disponíveis (cor, número de camadas, região de rolagem independente e tamanho de seleção) dependerá do modo de plano de fundo ativado no S-PPU, o que nos leva à próxima seção...

Modos

A S-PPU fornece muitas operações para planos de fundo, mas elas não podem ser escolhidas arbitrariamente. Em vez disso, existem oito modos de plano de fundo para escolher, cada um fornecendo um conjunto diferente de recursos :

• Modo 0: 4 camadas com 4 cores cada.
  • A paleta de cores é particularmente sem graça, já que este modo é o único que permite o maior número de camadas.
• Modo 1: 2 camadas com 16 cores cada + 1 camada com 4 cores.
  • Uma camada pode ser dividida em primeiro plano e plano de fundo.
  • Este é o modo mais comum usado.
• Modo 2: 2 camadas com 16 cores cada.
  • Este modo tem um efeito extra: as camadas podem ter cada uma de suas colunas roladas independentemente (semelhante aos efeitos do Game Boy, mas rolados verticalmente).
• Modo 3: 1 camada de plano de fundo com 128 cores + 1 plano de fundo com 16 cores.
  • As cores podem ser definidas como valores RGB em vez de usar as referências da CGRAM.
• Modo 4: Modo 2 e 3 combinados (rolagem de coluna + mapeamento de cores RGB).
  • A primeira camada possui 128 cores e a segunda possui apenas 4.
• Modo 5: 1 camada com 16 cores + 1 camada com 4 cores.
  • A área selecionada terá uma resolução de 512 x 224 píxeis, é espremido horizontalmente para caber na tela (o quadro de saída ainda é de 256 x 224 píxel!). Isso vem com o custo de renderizar tiles de 16x8 píxeis como um de 8x8, e de 16x16 píxeis como um de 8x16.
  • Além disso, a resolução vertical também pode ser expandida ativando entrelaçamento (atingindo 512 x 448 píxeis que é agora proporcional à dimensão de saída). Em troca, o mesmo efeito de espremer afetará também os tiles verticalmente. Isso é útil para os casos em que a tela precisa exibir quantidades extras de informações (ou seja, durante o modo multijogador/tela dividida).
• Modo 6: combinação do Modo 2 e 5 (alta resolução + rolagem de colunas), mas apenas uma camada com 32 cores é permitida.

Como você pode ver, os programadores agora têm a opção de priorizar o número de cores, camadas, efeitos ou resolução da área selecionada.

Sprites

Camada de sprite renderizada.

Uma área da memória chamada Object Attribute Memory (OAM) armazena uma tabela com referências de até 128 sprites com as seguintes propriedades :

• Tamanho: a PPU pode combinar até 16 pequenos tiles na forma de um quadrante de 4x4 tiles para construir um sprite.
• Referências do tile: o valor aponta para os tiles usados para desenhar o sprite.
• Posição na tela. Somente os sprites posicionados na área visível serão renderizados.
• Prioridade: como várias camadas se sobrepõem uma nas outras, o gráfico com a maior prioridade será exibido, isso também é determinado pelo modo de plano de fundo em uso.
• Slot da paleta de cores, permitindo escolher 9 slots da CGRAM.
• Flip X/Y.

A S-PPU pode desenhar até 32 sprites por linha de varredura, ultrapassar isso fará com que o S-PPU descarte os sprites com menor prioridade.

Resultado

Tada!

A S-PPU desenha cada varredura na tela dinamicamente, processando primeiro a parte respectiva de cada camada e depois as mesclando.

Uma das principais restrições dos jogos do NES era o fato de só poderem atualizar seus gráficos durante o V-Blank. O momento em que o feixe do CRT estava retornando ao ponto de partida fornecia um intervalo de tempo razoável para reorganizar alguns tiles sem quebrar a imagem.

Bem, agora, graças às novas capacidades do SNES, essa limitação ganhou um significado diferente.

Veja bem, como as novas unidades de DMA/HDMA agora permitem que os programadores realizem transferências de memória sem esperar pelo V-Scan , os jogos agora podem atualizar tiles, cores e registradores sem esperar que todo o quadro seja desenhado. Na verdade, podemos ir, além disso: como agora é possível mudar as configurações da S-PPU durante o meio do quadro, isso significa que é possível ativar diferentes modos de plano de fundo em diferentes estágios do mesmo quadro, abrindo a porta para novos projetos originais de jogos!

Aquela funcionalidade

Para ser sincero, eu ainda não mencionei a funcionalidade mais importante deste console...

Camada de plano de fundo renderizada.

Mapa de plano de fundo alocado.

Quadro renderizado na tela.
O primeiro quarto das linhas de varredura usa outro modo para simular a distância, o Modo 7 começa no segundo quarto (isso é possível graças ao HDMA).

Apresentando o Modo 7, mais um modo de plano de fundo, mas desta vez, com uma forma completamente diferente de trabalhar. Embora possa renderizar apenas uma única camada de fundo de 8 bpp, ele fornece a capacidade exclusiva de aplicar as seguintes transformações afins nesse plano :

• Translação.
• Escala.
• Rotação.
• Reflexão.
• Cisalhamento.

A S-PPU é controlada com uma matriz de rotação para alterar os parâmetros desse modo. Não entrarei em álgebra linear aqui, mas dependendo do efeito desejado, a CPU terá que executar algumas funções trigonométricas (seno e cosseno) para preencher as entradas dessas tabelas adequadamente. Isso é realmente caro para a 65C816, mesmo com o uso de precisão de ponto fixo. Por esse motivo, com a 5A22, a Ricoh adicionou registradores de multiplicação e divisão para aliviar alguns ciclos.

A propósito, observe que a lista de transformações não menciona a perspectiva, que é o que você vê no jogo de exemplo (F-Zero). Isso é alcançado alterando a matriz de rotação em cada chamada do HDMA, criando um efeito pseudo-3D no processo. Isso deve dar uma ideia de quão prático é a S-PPU!

Finalmente, devido ao alto número de cálculos necessários, o mapa de memória é alterado para otimizar o pipeline das duas PPUs, o primeiro processa o Tilemap (onde os tiles são referenciados) enquanto o segundo busca o Tileset (onde os tiles são armazenados).

Causas das quedas de quadros

Um outro tópico, você já se perguntou o que causa a lentidão dos jogos? Quando a interrupção V-Blank é chamada para permitir a atualização gráfica, às vezes o jogo ainda está executando um código pesado e pula a janela V-Blank, os gráficos não podem ser atualizados até a próxima chamada V-Blank e, como o quadro não foi atualizado, isso se manifesta como uma queda na taxa de quadros.

Isso também pode acontecer de forma oposta, um processamento extensivo durante um V-Blank não permitirá que o PPU produza o sinal de vídeo (pois o barramento está bloqueado). Assim, linhas pretas durante uma varredura serão exibidas, embora isso seja pouco perceptível, já que os quadros são atualizados 50 ou 60 vezes por segundo.

Uma saída de vídeo conveniente

Todos os avanços mencionados serão inúteis, a menos que o console envie a imagem para a TV através de um meio que ambos possam entender. Com o Super Nintendo, a empresa estreou algum tipo de conexões universais, mas proprietária, chamada de Multi Out, que pode transportar vários tipos de sinais simultaneamente, incluindo vídeo composto, S-Video e RGB .

Junto ao console, a Nintendo incluiu um cabo "Multi Out para video composto", já que essa era praticamente a forma comum de entrada de sinal nas TVs naquela época. Na Europa, no entanto, a porta SCART também era muito popular, já que muitos decodificadores e videocassetes dependiam dela. Uma grande coisa sobre o SCART é que ele também pode transportar muitos tipos de sinais, isso permite que o equipamento AV use o tipo de sinal mais adequado sem encontrar problemas de compatibilidade. Infelizmente, a Nintendo nunca lançou um cabo SCART oficial que aproveitasse os pinos RGB expostos no Super Nintendo.

No entanto, a Nintendo alterou o esquema de pinos de seus consoles PAL para cumprir o protocolo SCART e, ao fazer isso, substituiu o pino "sincronização de video composto" por um de 12 volts (que informa à TV para definir a proporção de 4:3). Então, mesmo que o Multi Out seja "universal", os cabos RGB resultantes, se houver, são específicos por região.

Penso que os benefícios reais do Multi Out começaram a se tornar evidentes durante os tempos atuais, pois permitiu que os usuários aproveitassem o sinal RGB com suas modernas televisões sem alterar os componentes internos do console. Embora, ao contrário do vídeo composto e do S-Video, o RGB exige um sinal extra de "sincronização". Para isso, o cabo pode ser conectado para capturar o sinal de sincronização do vídeo composto ou do S-Video; ou para melhores resultados, use uma linha de sincronização dedicada chamada "sincronização de vídeo composto". Mas, como mencionado no parágrafo anterior, apenas os consoles NTSC tinham essa última opção.