Eu também fiquei confuso quando eles mencionaram dessa maneira ai fui até olhar a placa mãe mas realmente fica DENTRO do RCP como o
@Warrior Of Light disse
Ao contrário da maioria dos hardwares para PC da época, o Nintendo 64 tem a vantagem de possuir seu próprio processador gráfico conhecido como Reality Co-ProcessorRCP. Isso liberou a CPU principal de fazer cálculos gráficos e poderia usar todo o seu poder de processamento para a lógica principal do jogo.
Na verdade, o RCP é dividido em duas partes distintas, uma para as transformações de Geometria conhecidas como Reality Signal Processor(RSP) e a outra para os cálculos por pixel conhecidos como Reality Display Processor(RDP).
O N64 Reality Display Processor (RDP) é usado para renderizar os polígonos de jogos do Nintendo 64 em pixels 2D que ele armazena no FrameBuffer pronto para ser exibido na tela
A funcionalidade do RDP foi descrita pela primeira vez em uma entrevista George Zacharyna revista, Next Generationonde ele descreveu o processador como a grande vantagem sobre o hardware Playstation, pois permitia recursos avançados, como correção de perspectiva de textura, que o hardware da Sony não poderia executar com eficiência 2
O RDP é usado depois que o Reality Signal Processor processa seus cálculos, para que você possa pensar no RSP como uma espécie de Vertex Shader e o RDP como uma espécie de Pixel Shader
Tarefas do RDP
- Lighting calculations
- Display List decoding
- Shading
- Level of Detail culling (LOD)
- Clipping
- Vertice Transforms (translate, scale, rotate)
- Wavetable Audio format decoding
- Midi Audio processing
- MP3 decoding (Conkers Bad Fur Day)
_
O N64 Reality Signal Processor (RSP) é a parte do Co-processador de realidade que lida com a transformação de dados. É um processador baseado em MIPS, como o processador principal R4000, mas também contém opcodes vetoriais de 8 bits adicionais
A funcionalidade do RSP foi descrita pela primeira vez em uma entrevista George Zacharyna revista, na Next Generationqual ele descreveu o processador como especialmente projetado para cálculos rápidos de matriz e adição, ao contrário dos processadores padrão PC RISC e CISC
Você pode pensar no RSP como uma versão mais poderosa do GTE (Geometry Transformation Engine) da Sony Playstation em termos de funcionalidade, mas o RDP foi um grande benefício sobre o Playstation, pois foi capaz de fazer efeitos como a correção de perspectiva de textura
Como você pode ver no chip RSP sem limite, existem duas seções de memória de 4KB, uma rotulada como IMEM e a outra como DMEM. IMEM é a abreviação de Memória de instrução e é apenas para instruções de montagem executadas no RSP, também conhecido como Microcode ou uCode.
DMEM é a abreviação de Data Memory e é usada para todos os dados que o RSP também precisa acessar, portanto, normalmente seriam dados de geometria ou áudio em que os cálculos estão sendo executados em
Microcódigo RSP
A capacidade de fazer cálculos rápidos de matriz e adição é crucial para gráficos 3D e síntese e descompressão de áudio, para tirar proveito dos programadores especializados em CPU, foi capaz de escrever uma montagem personalizada para esse processador conhecido como microcode.
O microcódigo (também conhecido como uCode) é semelhante à linguagem assembly, mas otimizado para o cálculo paralelo de milhares de cálculos de matriz por segundo, mas é muito menos documentado que o assembly tradicional e levou anos de desenvolvedores para descobrir como fazer o melhor uso do chip.
Microcódigo pré-escrito
Embora você possa inicialmente pensar no microcódigo RSP como semelhante à linguagem moderna do Shader, pois ambos são usados para implementar um pipeline de gráficos programáveis, esse não é exatamente o caso na prática. Na maioria das vezes, os desenvolvedores usavam o microcódigo escrito da Nintendo e o chamavam como se fosse um pipeline de função fixa normal.
Microcódigo personalizado
Não era comum os desenvolvedores escreverem seu próprio microcódigo para seus jogos até o final do ciclo de vida do N64. Portanto, a maioria dos jogos anteriores usava microcódigo pré-escrito desenvolvido pela SGI e Nintendo e o usava como um pipeline gráfico de função fixa.
De fato, a principal razão para a falta de desenvolvimento de microcódigo personalizado em jogos de terceiros é devido às ferramentas e documentação ruins fornecidas pela nintendo. Sem mencionar a complexidade da programação e nenhum depurador foi fornecido
1 .
O assistente de Microcódigo - Yoshitaka Yasumoto
Yoshitaka Yasumoto é creditado em muitos jogos como o programador de microcódigos (por exemplo, a história de Yoshi), mas a maioria dos jogos usa seu microcódigo sem dar crédito explícito, pois fazia parte do SDK oficial do N64.
Se você pesquisar um arquivo rom N64 pelo nome "Yoshitaka Yasumoto", provavelmente encontrará o microcódigo que ele escreveu. Isso funciona para a maioria dos jogos, a menos que eles usem seu próprio uCode personalizado.
Saída do Microcódigo
A saída principal do microcódigo RSP tende a ser comandos de rasterização gráfica para o RDP ou buffers de áudio para o DAC.
Microcódigos pré-escritos
A lista de microcódigos de RSP fornecidos pelo SDK oficial do Nintendo64 são os seguintes:
- gspFast3D - a maioria dos recursos, inclui névoa de sombreamento, etc.
- gspF3DNoN - igual ao Fast3D, mas sem quase recorte
- gspLine2D - não renderiza triângulos, por isso fornece um efeito de estrutura de arame
- gspSprite2D - eficiente para imagens em sprite 2D
- gspTurbo3D - Fast3Dprecisão mais rápida que a reduzida.
É muita informação mesmo, não é a toa que era complicado desenvolver jogos nele