Zenilto Soluções em Tecnologia
O Nintendo 64 foi lançado em 23/06/1996 no Japão, 29/09/1997 na América e 01/03/1997 na Europa
Uma breve introdução
O objetivo da Nintendo era fornecer aos jogadores os melhores gráficos possíveis, para realizar essa tarefa, eles fizeram parceria com um dos principais especialistas em gráficos do setor para produzir o chip final.
O resultado foi um bom console para toda a família… e um manual de instruções de 500 páginas para desenvolvedores.
Mostrando a revisão ‘NUS-CPU-03’.
Diagrama em blocos N64
CPU
O processador principal é um NEC VR4300 que roda a 93,75 MHz; uma versão binária compatível do MIPS R4300i da Silicon Graphics que inclui:
- Conjunto de instruções MIPS III: Sucessor do MIPS II com novas instruções de 64 bits. Palavras de 64 bits são chamadas palavras duplas.
- Um barramento interno de 64 bits conectado a um barramento de dados externo de 32 bits.
- Segmentação de instruções de 5 estágios: Até cinco instruções podem ser executadas simultaneamente.
- 24 KB de cache L1: Dividido em 16 KB para instruções e 8 KB para dados.
Também está incluído neste pacote uma FPU de 64 bits,a CPU identifica-a como um coprocessador (COP1),embora a unidade esteja instalada ao lado da unidade aritmética e só seja acessada através dessa unidade, portanto não há co-processamento em si.
Acesso simplificado à memória
A forma como a RAM é montada segue a Arquitetura de memória Unificada (UMA) onde toda a RAM disponível é centralizada em um só lugar e qualquer outro componente que exija RAM acessará este local compartilhado. O componente que arbitrar seu acesso é, neste caso, a GPU.
A razão pela qual este projeto foi escolhido é devido a uma economia considerável nos custos de produção, enquanto, por outro lado, a contenção de acesso aumenta se não for gerenciada corretamente.
Nenhum motor de DMA?
Devido à arquitetura de memória unificada, a CPU não tem mais acesso direto à RAM, por isso a GPU também fornece funcionalidade de Acesso direto à memória (DMA).
RAM disponível
Além da UMA, a estrutura da RAM é um pouco complicada, então vou tentar explicar em termos simples, aqui vai…
O sistema contém fisicamente 4,5 MB de RAM, no entanto, ele está conectado a um barramento de dados de 9 bits onde o 9º bit é reservado para a GPU (mais detalhes em diante). Como resultado, cada componente, exceto a GPU, só encontrará até 4 MB.
O tipo de RAM instalado na placa é chamado Rambus DRAM ou ‘RDRAM’ para abreviar, este foi outro design que competiu com sdram para se tornar o próximo padrão. O RDRAM é conectado em séries (onde as transferências são feitas um pouco de cada vez) enquanto o SDRAM usa uma conexão paralela (transfere vários bits de cada vez).
A latência do RDRAM é diretamente proporcional ao número de bancos instalados, portanto, neste caso, com a quantidade de RAM que este sistema possui, a latência resultante é importante.
Em contraste, a quantidade de RAM disponível neste console pode ser expandida instalando o acessório Expansion Pak : Uma pequena caixa de aparência elegante que inclui 4,5 MB. Curiosamente, o RAM deve ser terminado, para que o console seja sempre vendido com um exterminador (chamado Jumper Pak) instalado no lugar do Pak de Expansão. Agora, você pode se perguntar, e se ligarmos o console sem nenhum Pak instalado? Literalmente nada, você pega uma tela em branco!
Gráficos
O núcleo dos gráficos está em um enorme chip projetado pela Silicon Graphics chamado Reality Co-Processor que roda a 62,5 MHz. Este pacote contém muitos circuitos, então não se preocupe se você achar difícil de seguir, o subsetor gráfico tem uma arquitetura muito complexa.
Este design é baseado na filosofia de que a GPU não deve ser um rasterizador ‘simples’. Pelo contrário, você deve ser capaz de acelerar os cálculos geométricos (aliviando a carga da CPU) e, para isso, mais circuitos são necessários.
Dito isto, este chip é dividido em três módulos principais, dois dos quais são usados para processamento gráfico:
Reality Signal Processor: Processador de sinal de realidade
Também conhecido como RSP,é simplesmente outro pacote com uma CPU composta de:
- A Unidade Scalar: Uma CPU baseada no MIPS R400 que implementa um subconjunto de instruções R400.
- A Unidade Vetorial: Um coprocessador que executa operações vetoriais com registros de 32 bits de 128 bits. Cada registro é separado em oito partes para operar oito vetores de 16 bits por vez (assim como as instruções SIMD nas CPUs convencionais).
- Controle do sistema : Outro coprocessador que cobre funções de DMA e controla seu módulo vizinho, RDP (mais sobre isso em breve).
Para operar este módulo, a CPU armazena na RAM uma série de comandos chamados Lista de exibição, juntamente com os dados a serem manipulados, em seguida, o RSP lê essa lista e aplica as operações necessárias nos dados. A funcionalidade disponível inclui transformações geométricas (como projeção de perspectiva), recorte e iluminação.
Parece simples, mas como você realiza essas operações? Bem, aqui está a parte interessante: Ao contrário de seus concorrentes (PS1 e Sega Saturn), o motor de geometria não é fixo. Em vez disso, o RSP contém alguma memória (4 KB para instruções e 4 KB para dados) para armazenar microcódigo, um pequeno programa, com não mais de 1000 instruções, que implementa o tubo gráfico. Em outras palavras, ele dirige a Unidade Scalar como deve operar nossos gráficos. A CPU envia microcódigo enquanto o programa está em execução.
A Nintendo forneceu diferentes versões de microcódigo para escolher e, semelhante aos modos de fundo do SNES, cada uma equilibra os recursos à sua maneira.
Arquitetura RSP
Reality Display Processor: Processador de exibição de realidade
Uma vez que o RSP termine de processar os dados de nossos polígonos, ele começará a enviar comandos de rasterização para o próximo módulo, o RDP, para desenhar o quadro. Estes comandos são enviados por um ônibus dedicado chamado XBUS ou pela RAM principal.
RDP é outro processador (desta vez com funcionalidade fixa) que inclui vários motores usados para mapear texturas em nossos polígonos, misturar cores e compor o novo quadro.
Isso pode processar triângulos ou retângulos, este último é útil para desenhar sprites. O motor de rasterização RDP contém os seguintes blocos:
- Um Rasteriser– Atribui o bitmap inicial que servirá como um buffer de quadro.
- Uma Unidade de Textura: Processa texturas usando 4 KB de memória dedicada (chamada ‘TMEM’) para permitir que até oito telhas sejam usadas para a textura. Você pode realizar as seguintes operações neles:
Filtragem bilinear: Mapeia a textura 2D selecionada sobre a figura 3D e a suaviza para evitar áreas pixeladas. Um filtro ‘completo’ requer quatro pontos para aplicar a interpolação, no entanto, este console usa apenas três(interpolação triangular)que causam algumas anomalias. Portanto, certas texturas terão que ser ‘adaptadas’ de antemão.Mip-Mapping: Seleciona automaticamente uma versão reduzida da textura dependendo do seu nível de detalhe. Isso evita calcular grandes texturas que seriam vistas longe da câmera e, assim, evitar ‘aliasing’.Se ativado, o N64 mapeia texturas usando filtragem trilinear. Este novo algoritmo também interpolará entre mipmaps para suavizar mudanças repentinas no nível de detalhes.
Correção da perspectiva: Algoritmo escolhido para mapear texturas em triângulos. Ao contrário de outros algoritmos, ele leva em conta o valor de profundidade de cada primitivo, alcançando melhores resultados. - Um combinador decores : mistura e interpola múltiplas camadas de cores (por exemplo, para aplicar luzes).
- Um liquidificador: Mistura pixels sobre o buffer de quadro atual para aplicar translucência, anti-aliasing, neblina ou dithering. Ele também executa z-buffering (mais sobre isso mais tarde).
- Uma interface memória: Usada pelos blocos acima para ler e enviar o buffer de quadro processado para ram e/ou preencher o TMEM.
O RDP fornece quatro modos de operação, cada um combinando esses blocos de forma diferente para otimizar operações específicas.
Uma vez que este módulo requer a atualização constante do buffer de quadro, ele deve lidar com a RAM de forma mais eficaz: Lembra-se do incomum ‘byte’ de 9 bits? O nono bit é usado para cálculos relacionados ao buffer de quadros (como tampão z e antialiasing) e só pode ser acessado através da interface Memória.
Arquitetura RDP
O quadro obtido deve ser enviado ao Video Encoder para poder visualizá-lo na tela(O DMA e a Interface de Vídeo são essenciais para realizá-lo).
No papel, as capacidades máximas são uma profundidade de cor de 24 bits (16,8 milhões de cores) e uma resolução de 720×576 (ou 640×480 na região do NTSC). É mencionado como “teórico” como fazer uso de capacidades máximas pode ser muito caro em termos de recursos, de modo que os programadores tenderão a usar valores mais baixos para fornecer recursos suficientes para outros serviços.
Demonstração rápida
Vamos colocar todas as explicações acima em perspectiva, para isso vou pegar emprestado o Super Mario 64 da Nintendo para demonstrar, em palavras malucas, como um quadro é formado:
Modelos e sombreamento
Visão primitiva de nossa cena Para salvar polígonos, alguns personagens são modelados com sprites (quadrilaterals)
Para começar, nossos modelos 3D estão no cartucho ROM, mas para manter a largura de banda constante, precisamos copiá-los para RAM primeiro.
Então, é hora de construir a cena usando nossos modelos, a CPU poderia fazê-lo por conta própria, mas isso pode levar uma vida inteira, então a tarefa é delegada à RCP. A CPU simplesmente enviará comandos para a RCP, isso é feito executando as seguintes tarefas:
- Componha a Lista de Exibição que contém as operações a serem realizadas pelo RSP e armazene-a em RAM.
- Aponte para o RSP onde está localizada a Lista de Exibição.
- Envie o microcódigo para o RSP para iniciar a Unidade Scalar.
Em seguida, o RSP começará a executar as tarefas e o resultado será enviado ao RDP sob a forma de comandos de rasterização.
Texturas e rasterização
Quadro renderizado Overscaling (640×480) por razões de demonstração
Até agora conseguimos processar nossos dados e aplicar alguns efeitos sobre eles, mas ainda temos que:
- Aplique texturas e outros efeitos.
- Desenhe um buffer de quadros, para que você possa exibi-lo na tela.
Como você pode adivinhar, essas tarefas serão executadas pelo RDP. A CPU enviará os dados (como texturas) colocando-os em RAM, este módulo tem um motor fixo, mas permite selecionar o modo de operação com base na tarefa que será realizada, ajudando a melhorar a taxa de quadros.
Uma vez que o RDP termine de processar os dados, ele gravará o bitmap resultante para o buffer de quadro que está dentro da RAM. Uma vez concluída, a CPU deve transferir o novo quadro para a Interface de Vídeo (de preferência usando o DMA) que, por sua vez, o enviará para o Codificador de Vídeo para visualização.
Uma solução moderna para o problema das superfícies visíveis
Se você leu sobre problema de visibilidade de superfície sem fim e pode pensar que a única solução para isso é por “classificação de polígono”. Bem, pela primeira vez nesta série, o RDP introduz uma solução baseada em hardware chamada Z-buffering. Simplificando, o RDP aloca um novo buffer chamado Z-Buffer na memória. Isso tem as mesmas dimensões de um buffer de quadro, mas em vez de armazenar valores RGB (vermelho, verde e azul), cada entrada contém a profundidade do pixel mais próximo em relação à câmera (chamada ‘z-value’).
Uma vez que o RDP rasteriza os vetores, o valor z do novo pixel é comparado com o respectivo valor no buffer Z. Se o novo pixel contiver um valor z menor, isso significa que o novo pixel está posicionado na frente do pixel anterior, por isso é substituído no buffer de quadro e z-buffer. Caso contrário, o pixel é descartado.
Em geral, o novo algoritmo é meu benefício: os desenvolvedores não precisam mais se preocupar em implementar métodos para classificar polígonos baseados em software que tendem a consumir alguns recursos de CPU. No entanto, o buffer Z não impede o processamento de geometria desnecessária (eventualmente descartada ou sobreescrita, que consomem recursos de qualquer maneira). Para fazer isso, o motor do jogo pode optar por incluir um algoritmo de ‘abate de oclusão’ para descartar geometria que não será visível, o mais rápido possível.
Segredos e limitações
É claro que a SGI investiu muita tecnologia nesse sistema. No entanto, este ainda é um console para a casa e, como tal, ele deve manter um baixo custo. Por lá, certas decisões se tornaram desafios para os programadores:
Devido ao grande número de componentes e operações na tubulação gráfica, a RCP acabou sendo altamente suscetível a bolhas de segmentação: Uma situação indesejável caracterizada por subcomponentes que permanecem inativos por períodos consideráveis de tempo porque os dados necessários estão atrasados na chegada.
Isso sempre se manifestará na degradação do desempenho e depende do programador para evitá-los. Embora para facilitar as coisas, algumas CPUs como a Unidade Scalar implementam um recurso chamado Bypassing que permite executar declarações semelhantes em um ritmo mais rápido para evitar passar por fases de execução que podem ser omitidas. Por exemplo, se tivermos que calcular várias declarações (soma) de uma só vez, não há necessidade de escrever o resultado da soma para o registro do destinatário e, em seguida, lê-lo novamente para executar o próximo. Em vez disso, você pode usar o mesmo registro intermediário para realizar todas as adições e, no final, enviar o resultado para o registro do destinatário assim que o último for concluído. ADDADDADD
Memória textura
O RDP usa 4 KB de TMEM (‘Textura Memory’) para processar texturas. Infelizmente, na prática 4 KB acabou por ser insuficiente para texturas de alta resolução. Além disso, se a aplicação de mipmapping for usada, a quantidade de memória disponível é reduzida pela metade.
Como resultado, alguns jogos usam cores sólidas com sombreamento Gouraud (como Super Mario 64)enquanto outros fazem uso de texturas pré-calculadas (por exemplo, quando várias camadas precisam ser misturadas).
Saída universal de vídeo
A Nintendo continuou a usar a saída “universal” chamada Multi Out como seu antecessor, infelizmente não transmite mais o sinal RGB. Isso soa como outra medida para cortar custos, já que o mesmo sinal não tinha sido aproveitado no console anterior.
A boa notícia é que todos os três canais podem ser reconstruídos nas primeiras revisões do console soldando alguns cabos e instalando um amplificador de sinal (tende a ser barato). Isso ocorre porque o conversor de vídeo digital-analógico envia um sinal RGB para o codificador de vídeo. No entanto, as unidades subsequentes combinaram os dois chips, então a única solução disponível é exceder o vídeo DAC e codificar com algum chip especializado que pode expor o sinal RGB.
Áudio
Antes de entrar em detalhes, vamos definir os dois pontos opostos do subsistema de áudio:
- Nosso ponto de partida é o ROM do cartucho, contém dados que só a CPU pode interpretar.
- O ponto final é o conversor Digital-para-Analógico ou ‘DAC’, que só entende dados codificando a forma de onda.
Então, como conectamos as duas pontas? Os consoles normalmente incluem um chip de áudio dedicado que faz o trabalho para nós. Infelizmente, o Nintendo 64 não tem esse chip dedicado, então essa tarefa é distribuída através desses componentes:
- CPU principal : Transfere dados de áudio do rom do jogo para RAM e, em seguida, cria listas de áudio para serem usadas pelo RSP.
- RSP: Com o uso de mais microcódigo, interpreta listas de áudio previamente armazenadas em RAM e realiza as operações necessárias nos dados de áudio. Isso, por exemplo, inclui: Descompactar amostras ADPCM e aplicar efeitos.
Sequencia e misture dados MIDI usando bancos de áudio também armazenados em RAM.
Os dados resultantes são, como esperado, dados que contêm a forma de onda. Estes são enviados para o bloco áudio interface ou ‘IA’ que irá transferi-los para o conversor Digital-para-Analógico. A forma de onda resultante contém dois canais (já que nosso sistema é estéreo) com uma resolução de 16 bits cada.
Resumo de como o motor de áudio tende a ser programado
Segredos e limitações
Por causa desse projeto, as limitações deste sistema dependerão da implementação:
- A frequência da amostra pode ser de até 44,1Hz, mas usar a frequência máxima requer muitos ciclos de CPU.
- Não há um limite rigoroso no número de canais, tudo depende de quanto você é capaz de misturar o RSP (muitas vezes em torno de 16-24 canais se a ADPCM ou .100 for processado se PCM).
- A memória é outra questão a ter em mente. Enquanto a competição forneceu mídia maior (por exemplo, CD-ROMs) e memória de áudio dedicada, os cartuchos Nintendo 64 contêm muito menos capacidade (sem mencionar o espaço reservado para música) e devem compartilhar a RAM principal com outros componentes. Por essas razões, os jogadores podem notar que as portas N64 contêm música de menor qualidade ou repetitiva. Um método para superar essa limitação foi implementar um sequenciador em software que pudesse ‘construir’ amostras enquanto o jogo estava em execução, isso requer um banco de som (semelhante à música MIDI).
Sistema Operacional
Como o PS1 e o Saturn, os jogos N64 falam diretamente com o hardware. No entanto, não há rotinas de BIOS disponíveis para simplificar algumas operações. Como substituto, os jogos incorporam um pequeno sistema operacional que fornece uma boa quantidade de abstração para lidar eficientemente com a CPU, GPU e I/O.
Este não é o sistema operacional de desktop convencional que podemos imaginar no início, é apenas um micro-kernel com o menor tamanho possível que fornece a seguinte funcionalidade:
- Multi-Threading (note que a CPU é single-core).
- Agendamento e Preempção.
- Acesso ao cadastro simplificado e I/O.
O kernel é armazenado automaticamente ao usar bibliotecas Nintendo. Além disso, se os programadores optarem por não incluir uma das bibliotecas, a respectiva parte do kernel será removida para evitar o desperdiçado espaço do cartucho.
Entrada/Saída
Como você sabe, a I/O não está diretamente conectada à CPU, então o terceiro módulo de RCP (que não mencionei até agora) serve como uma interface de I/O. Basicamente, ele se comunica com a CPU, drivers, cartucho de jogo e DACs de áudio/vídeo.
Jogos
A Nintendo se agarrou ao cartucho como um meio de armazenamento e, como resultado, os jogos desfrutavam de larguras de banda mais altas (entre 5-50 MB/s, dependendo da velocidade da ROM) enquanto custavam mais para produzir. O maior cartucho do mercado é de 64 MB.
Dentro dos cartuchos, os fabricantes podem incluir memória extra (na forma de EEPROM, flash ou SRAM com uma bateria) para armazenar jogos, no entanto não é um requisito rigoroso, pois alguns acessórios também podem ser usados para armazenar o progresso.
Acessórios
O controlador Nintendo 64 inclui um conector de acessórios plug-in, alguns dos quais são:
- Controller Pak: Outro meio (semelhante ao Cartão de Memória Sony) usado para armazenar jogos e levá-los para outros consoles.
- Rumble Pak: Contém um pequeno motor para fornecer vibração, útil para mergulhar o jogador na “experiência do jogo”.
Todos os acessórios conectados ao controlador são manuseados pela Interface Periférica.
Além disso, este console incluiu um conector especial na parte inferior de sua placa-mãe que era destinado a ser usado pela unidade Disc que nunca foi lançado. Este era uma espécie de “piso extra” contendo um leitor de disco proprietário. A unidade só foi liberada no Japão e eventualmente cancelada no resto do mundo.
Kit de Desenvolvimento
De um modo geral, o desenvolvimento para o N64 foi feito principalmente em C, embora a montagem também fosse necessária para obter melhor desempenho. Embora este sistema contivesse um conjunto de instruções de 64 bits, as instruções de 64 bits raramente eram usadas, pois, na prática, instruções de 32 bits resultaram em uma execução mais rápida e exigiu metade do armazenamento.
Por outro lado, as bibliotecas continham várias camadas de abstrações para comandar a RCP. Por exemplo, a Interface Binária Gráfica ou ‘GBI’ era uma estrutura projetada para montar listas de exibição com mais facilidade, o mesmo aplicado às funções de áudio (sua estrutura era chamada de Interface Binária de Áudio ou ‘ABI’).
Quanto ao uso de microcódigo, a Nintendo forneceu várias opções de microcódigo escritas para escolher. No entanto, no caso de os desenvolvedores quererem modificá-lo, eles chegariam a uma tarefa árdua: as instruções da Unidade Scalar não foram inicialmente documentadas (por comando da Nintendo, é claro). Mais tarde, a empresa mudou de posição e a SGI acabou publicou alguma documentação para permitir o desenvolvimento de um novo microcódigo.
O hardware usado para o desenvolvimento de videogames incluía estações de trabalho fornecidas pela SGI, como a máquina Indy que veio com uma placa extra chamada U64 contendo o hardware do console e I/O. Ferramentas também foram fornecidas para computadores com Windows instalados.
Outras ferramentas fornecidas por terceiros consistiam em cartuchos com um cabo longo que se conectava à estação de trabalho. Este cartucho foi inserido em um Nintendo 64, mas incluiu um circuito interno para redirecionar comandos de leitura do console para ram de estação de trabalho. Uma vez terminado, o console ligaria e começaria a ler a partir da RAM (no computador), isso permitia realizar a implementação e depuração do jogo.
Antipirataria / Bloqueio da Região
O sistema antipirataria é uma continuação do CIC SNES. Como você sabe, a detecção de pirataria e o ‘bloqueio de região’ são possíveis pelo chip CIC (que deve estar presente em cada cartucho de jogo autorizado), o Nintendo 64 melhorou este sistema exigindo que diferentes jogos tivessem uma variante específica do CIC para garantir que o cartucho não fosse falsificado ou contivesse um clone da CIC. A interface periférica ou ‘PIF’ realizou verificações usando checksums no início e durante a execução do jogo para monitorar o CIC instalado no cartucho.
Se por algum motivo o PIF considerar que o cartucho inserido é inválido, ele bloqueia a execução do jogo.
O bloqueio de região é realizado alterando ligeiramente a forma externa do cartucho entre as diferentes regiões para que o usuário não possa inserir fisicamente o jogo em um N64 de uma região diferente.
Em geral, não havia muita preocupação com a pirataria graças ao uso do cartucho como meio, embora os preços dos jogos fossem três vezes maiores do que os dependentes de CD.
Portas não usadas
Por mais bobo que pareça, a Nintendo deixou uma ‘porta’ aberta: a porta Disk Drive.
Algumas empresas, por meio da engenharia reversa, estudaram a interface para o desenvolvimento de hardware proprietário; Os novos produtos lançados têm que preocupar a Nintendo por causa de suas capacidades de rodar jogos piratas.
Acho que o que vale a pena mencionar é o Doctor v64,este dispositivo tem a mesma forma que a unidade de disco, mas inclui uma unidade CD-ROM que é usada para gravar o conteúdo do cartucho para um CD, embora o oposto (leia a ROM de um CD) também seja possível.
Emulação
Quando eu era criança eu costumava jogar alguns jogos N64 em um PC com um Pentium II usando um emulador, não era super lento, mas agora eu me pergunto como o leite foi capaz de emular alegremente uma máquina tão complexa de 64 bits já que, entre outras coisas, meu PC mal tinha RAM suficiente para manter os gráficos integrados vivos.
A verdade é que, enquanto jogar a arquitetura deste console pode ser uma tarefa bastante difícil, coisas como o microcódigo dão uma pista do que o console está tentando fazer, e como os emuladores não têm que ser precisos, eles podem aplicar otimizações suficientes para fornecer mais desempenho em troca de emulação idêntica.
Outro exemplo são as instruções de 64 bits, uma vez que os jogos mal as usam, a taxa de emulação raramente diminui quando executada em um computador de 32 bits.
Créditos e fontes:
