Entendendo o projeto do sistema de vídeo do Super Nintendo
(fabiensanglard.net)- O vídeo do SNES foi projetado, dentro dos limites das TVs CRT e do sinal NTSC do início dos anos 1990, para uma tela de 256x224, taxa de quadros de 60,098 Hz e intervalos de blanking adequados
- O CRT não funciona com grade de pixels, mas com canhões de elétrons, sinais RGB e HSYNC/VSYNC para desenhar as linhas de varredura; progressivo e entrelaçado também se diferenciam pela posição dos sinais de sincronização
- Como o SNES não podia ter um oscilador de vídeo dedicado, ele dividia o clock mestre de 21,47727 MHz para gerar um dot clock de 5,3693175 MHz e, com a combinação de 262 linhas e 341 dots, chegava a 60,098 Hz, diferente do padrão NTSC de 59,94 Hz
- O modo básico é composto por 224 linhas visíveis e 38 linhas de VBLANK entre as 262 linhas, além de 256 dots visíveis e 85 dots de HBLANK entre os 341 dots, garantindo ao PPU tempo para trabalhar no buffer de linha dos sprites
- O SNES PAL oferecia outro oscilador e um modo overscan de 240 linhas para se ajustar ao ambiente de 50 Hz e 312,5 linhas, mas como a maioria dos jogos era baseada em 224 linhas, faixas pretas e execução 17% mais lenta eram comuns
Onde a TV CRT limitava o projeto
- O alvo principal da saída de vídeo do SNES era uma TV CRT padrão, e na época as TVs recebiam transmissão analógica NTSC por antena ou vídeo externo pela entrada AUX
- A entrada auxiliar de uma TV comum era composta pelo conector amarelo de vídeo composto e pelos conectores branco e vermelho de áudio estéreo
- Um CRT pode ser visto como um dispositivo de desenho de linhas na faixa de 15 kHz, capaz de traçar cerca de 15 mil linhas por segundo
CRT funciona com linhas de varredura e sinais, não com pixels
- Dentro do CRT há três canhões de elétrons, e os elétrons são desviados para cima/baixo e esquerda/direita por ímãs verticais e horizontais
- Os elétrons em si não têm cor, e a máscara faz com que os elétrons de cada canhão atinjam a faixa de fósforo da cor correta
- Um CRT não tem pixels, e as fendas também não são pixels
- Uma TV de alta resolução tem fendas menores, o que permite representar com mais fidelidade o mesmo sinal de cor na direção horizontal
- O CRT recebe cinco sinais por quatro fios
- Os sinais Red, Green e Blue são ligados diretamente a cada canhão de elétrons
- Se não houver sinal nas três linhas RGB, nenhum elétron é disparado e a cor exibida é preta
- O fio branco é o Composite Sync (CSYNC), que carrega HSYNC e VSYNC juntos
- O CRT não gera o VSYNC por conta própria; ele recebe o sinal de sincronização enviado pelo sistema externo para alinhar a posição dos canhões de elétrons
Diferença entre progressivo e entrelaçado
- O CRT desenha uma linha da esquerda para a direita e, ao receber HSYNC, volta para a esquerda da tela em X=0
- Ao receber VSYNC, retorna para o topo da tela em Y=0
- Enquanto o canhão se move para a direita, ele segue uma trajetória inclinada para baixo, então a linha seguinte após o HSYNC é desenhada abaixo da anterior
- Se o VSYNC ocorrer no mesmo ponto do último HSYNC, temos varredura progressiva, em que os campos são desenhados na mesma posição
- Se o VSYNC ocorrer entre dois HSYNC, temos entrelaçamento, em que as linhas do campo seguinte entram entre as do campo anterior
- O entrelaçamento dobra a resolução vertical, mas a taxa de atualização de cada linha cai pela metade
- O NTSC envia dois campos a cerca de 30 Hz, então o CRT foi preparado para manter o espaçamento entre linhas do entrelaçamento; ao desenhar em progressivo, aparecem espaços pretos de scanline
Especificação NTSC e limites de um projeto simples
- O projeto do SNES precisava ficar próximo dos valores que uma TV NTSC conseguiria processar
- Proporção de tela: 4:3
- Número de linhas por campo: 262,5
- Número de dots por linha: 341,25
- Frequência de campo: 59,94 Hz
- O NTSC em preto e branco era originalmente 60 Hz, mas o NTSC colorido reduziu a frequência em 0,1% para manter compatibilidade retroativa e evitar artefatos ao adicionar cor
- Em uma abordagem simples, seria possível escolher 262 linhas em progressivo, 350 dots e 59,94 Hz, exigindo um dot clock de 5.496.498 Hz
- Mas esse projeto não servia para o SNES real
- Por restrições de custo, não era possível ter um oscilador dedicado só para o sistema de vídeo, então os subsistemas precisavam dividir o oscilador mestre
- O CRT pode continuar disparando elétrons durante o retorno da imagem, então era necessário lidar com overscan e blanking
Blanking e escolha da resolução vertical
- Se os elétrons continuarem sendo disparados enquanto a posição do canhão é resetada horizontal ou verticalmente, surgem artefatos visíveis
- A TV faz overscan, exibindo uma imagem um pouco maior que a tela, e esse grau varia de TV para TV
- Depois de VSYNC e HSYNC, a posição do canhão oscila por um breve momento, então é preciso interromper a emissão de elétrons até se obter uma linha estável
- O intervalo sem emissão após o VSYNC é o VBLANK
- O intervalo sem emissão após o HSYNC é o HBLANK
- Sistemas concorrentes da época também usavam blanking
- Capcom CPS-1: 262 linhas, VBLANK de 38 linhas, 224 visíveis, 59,6294 fps
- Sega Genesis: 262 linhas, VBLANK de 38 linhas, 224 visíveis, 59,9227 fps
- Neo-Geo AES: 264 linhas, VBLANK de 40 linhas, 224 visíveis, 59,18 fps
- O SNES divide 262 linhas em 224 linhas visíveis + 38 linhas de blanking
- 224 é divisível por 16, o que se encaixa bem no pipeline gráfico baseado em tiles de 16x16
Resolução horizontal e 60,098 Hz
- O SNES divide o clock mestre de 21,47727 MHz por 4 e usa um dot clock de 5,3693175 MHz
- Taxa de quadros, número de linhas, dots por linha e dot clock estão todos ligados entre si
- Ao usar como alvo 59,94 Hz e 262 linhas, o resultado fica em cerca de 342 dots por linha, mas por causa de artefatos da portadora na saída composta os engenheiros da Nintendo precisaram usar 341 dots
- Com essa combinação, a taxa de quadros do SNES fica em 5,3693175 MHz / (341 * 262) = 60,098 Hz
- 60,098 Hz é diferente dos 59,94 Hz do NTSC, mas ainda funciona dentro da tolerância do CRT
Por que 256x224 virou a tela padrão
- Não era possível usar os 341 dots de uma linha inteira como área visível; era preciso um HBLANK para esconder instabilidade, artefatos e overscan da TV
- Com 224 linhas, a largura visível próxima de 4:3 seria 224 * 4/3 = 298 dots
- Como o pipeline de tilemap usa tiles de 16x16, os valores possíveis eram 304, 288, 272, 256, 240 etc.
- 304 dots é o valor mais próximo de uma imagem com pouca distorção
- Havia também a restrição de que o PPU precisava preencher o buffer de linha dos sprites durante o HBLANK
- Se fossem escolhidos 304 dots visíveis, o HBLANK ficaria em 37 dots, cerca de 7 µs
- É possível que fosse necessário mais tempo para buscar os dados de até 128 sprites
- A escolha final foi 256 dots visíveis + 85 dots de HBLANK
- O PPU ganhava cerca de 16 µs durante o HBLANK
- A proporção da área visível não era 4:3, mas 8:7, o que gerava uma leve distorção quando exibida no CRT
O compromisso dos modos de alta resolução
- A configuração básica de vídeo do SNES é resolução overscan de 341x262, resolução visível de 256x224 e taxa de quadros de 60,098 Hz
- 99% dos jogos usam essa configuração, mas o SNES também tem modos de alta resolução que dobram a resolução vertical ou horizontal
- A resolução vertical de 448 linhas pode ser obtida emitindo o VSYNC meio linha após o último HSYNC, criando um quadro entrelaçado
- Nesse caso, cada linha é atualizada a 60,098/2 = 30,049 Hz
- Há cintilação e o resultado visual não é muito agradável, mas a resolução vertical aumenta
- Dobrar a resolução horizontal era mais difícil porque não existia o dot clock necessário
- O SNES desloca ligeiramente o segundo campo na horizontal para que os pontos caiam entre os do campo anterior
- O resultado é meia taxa de quadros e forte borrão de cor
- fullsnes.txt resume exemplos de uso de alta resolução em vários títulos
- Logotipo da Nintendo em Donkey Kong Country 1: 512x224, BgMode5
- Tela de configurações de Seiken Densetsu 2: 512x224, BgMode5
- RPM Racing: introdução e jogo em 512x448, BgMode5+Interlace
- No caso de Ranma 1/2, na prática é 256x224, mas o entrelaçamento foi ativado por acaso e gerou cintilação desnecessária
PAL, SECAM e os problemas do SNES europeu
- As TVs europeias usavam PAL em vez de NTSC, e na França também havia SECAM
- O ambiente PAL espera exatamente 50 Hz e 312,5 linhas por campo
- O SNES PAL trazia um oscilador de 17,7344750 MHz no lugar dos 21,4772700 MHz do NTSC
- O chip S-CLK aplica um tratamento 6/5 e depois divide por 4, gerando um dot clock de 5,32034250 MHz
- Se fossem usados apenas gráficos de 224 linhas, surgiriam grandes faixas pretas acima e abaixo da área visível
- Para reduzir isso, havia um modo overscan que ampliava as linhas visíveis para 240
- Essas 16 linhas extras equivalem à altura de um tile
- Na prática, a maioria dos títulos foi feita para 224 linhas e quase não usava esse modo
- Apenas 12 títulos o utilizam
- Super Mario World lida com isso no PAL ampliando o campo de visão vertical
- Tanto NTSC quanto PAL usam proporção 4:3, então a imagem PAL fica um pouco mais comprimida verticalmente do que a NTSC
- Muito código de jogos não levava em conta que o VSYNC ocorria a 50,00697891 Hz em vez de 60,098 Hz, e como resultado os jogos rodavam 17% mais devagar que o pretendido
Sinal de saída e conector AV
- Os sinais RGB e de sincronização vistos antes são sinais puros para dirigir um CRT diretamente, mas a maioria das TVs reais não aceitava esses sinais de forma direta
- Muitas TVs tinham apenas a entrada composta amarela na traseira, e alguns modelos mais avançados ofereciam entrada S-Video
- O SNES convertia os sinais destinados ao CRT tanto para vídeo composto quanto para S-Video
- O conector AV fornecia vários formatos de saída sem descartar sinais
- Red, Green, Blue
- C-Sync
- S-Video baseado em Luminance e Chrominance
- Composite Video
- +5V DC
- Ground
- Left Audio, Right Audio
- TVs europeias, especialmente as da França, frequentemente vinham com conector SCART, o que permitia fabricar cabos que levavam o sinal de forma mais direta ao CRT
- Como resultado, usuários europeus podiam jogar versões 17% mais lentas e com faixas pretas, mas com fidelidade de imagem mais alta
1 comentários
Comentários do Hacker News
É muito provável que 224 não seja um número escolhido ao acaso. Ele é divisível por 16 (224/16=14), então se encaixa bem com os tilemaps do pipeline de renderização gráfica
Quando eu era criança e mexia em várias coisas tentando aprender programação de jogos, só fui entender isso muito tempo depois, e aí fez muito sentido. Em CGA/EGA/VGA, modos 320x200 eram comuns; o NES e o SNES eram 256x224, o que na prática tinha muito a ver com as limitações da TV
Por outro lado, o Pac-Man de arcade era 288x224, então os clones de Pac-Man para PC nunca pareciam “certos”, e até a versão de Pac-Man para NES feita pela Namco não encaixava. Os tiles do mapa ficavam menores e os personagens enormes, ou virava um mundo com rolagem como nas versões de Game Boy/Tengen, ou entravam concessões como distorção e mapas não originais; tentar jogar um “arcade” em casa acabava parecendo estranho e frustrante
Depois de aprender a arquitetura das máquinas e como os sprites funcionavam, cheguei à conclusão de que, no fim, não havia outra escolha, e isso foi uma grande revelação. A coisa fica ainda mais complicada quando se considera que, nessa resolução no PC, os pixels não eram quadrados
Desde então, sempre que vejo um port ou clone de Pac-Man, começo imediatamente a conferir o tamanho do mundo, o tamanho dos tiles e o tamanho dos sprites
Esse overscan, porém, variava de uma TV para outra, e TVs modernas ou emuladores normalmente mostram todas as 240 linhas
A resolução vertical do SNES podia ser configurada para 224 ou 240 linhas, como no texto. A maioria dos jogos usava 224 linhas, porque isso aumentava o tempo de vertical blanking e dava mais tempo para transferir gráficos para a PPU
O texto de Rodrigo Copetti sobre a arquitetura do SNES também vale a leitura: https://www.copetti.org/writings/consoles/super-nintendo/
É verdade que 59,94Hz é um número estranho, mas, até onde sei, não existe rede elétrica de 30Hz. A América do Norte e algumas outras regiões onde o NTSC foi projetado usam rede elétrica de 60Hz
https://en.wikipedia.org/wiki/Mains_electricity_by_country
A frequência mais alta gerada em uma TV em preto e branco era a taxa de varredura horizontal, que era um múltiplo da taxa de quadros. Com a adição do sinal colorido NTSC, que usa uma portadora de 3,579545MHz, a frequência máxima dentro da TV ficou muito mais alta e, para manter o hardware simples, as frequências mais baixas continuaram sendo ajustadas como divisores dessa frequência máxima, isto é, da portadora de cor. Como resultado, a taxa de quadros passou a ser 59,94 campos por segundo
A parte sobre jogos em regiões PAL não terem sido ajustados para o VSYNC de 50,00697891 Hz e, por isso, rodarem 17% mais devagar que o padrão de 60,098 Hz bateu forte demais
Não é algo exclusivo do Super Nintendo, mas me fez lembrar de quando vi ou joguei Sonic the Hedgehog no Mega Drive (Genesis) pela primeira vez. Achei meio sem graça, porque parecia mais lento e arrastado do que a versão de Master System; só depois que o YouTube surgiu é que percebi como a diferença de velocidade entre NTSC e PAL era enorme. E não era só a velocidade do jogo: a música também soava horrível em PAL
Mesmo na era dos 16 bits eu sabia da existência de PAL e da necessidade das “caixas pretas”, mas não tinha ideia de que a diferença era tão grande. Acho que, na época, as revistas de consoles diziam que a diferença era pequena na maioria dos jogos; uma exceção era que a versão de DooM para SNES tinha uma tela maior na versão NTSC
Quando eu era criança, eu era bom em Punch-Out de NES e conseguia derrotar Mr. Dream ou Mike Tyson no primeiro round; pensando agora, eu estava jogando a versão PAL. Se eu tivesse participado de um campeonato nos EUA, teria sido destruído no primeiro round, e provavelmente teria certeza de que alguém tinha me armado uma cilada
Por exemplo, em uma taxa de quadros menor, Samus e os projéteis se movem mais pixels por quadro, então fica mais fácil atravessar objetos; este glitch de portão só é possível em PAL: https://www.youtube.com/watch?v=RvyIwtO_qgM
As constantes de física de Samus e o timing das animações dela foram ajustados para a nova taxa de quadros, mas inimigos, cutscenes e outros elementos do ambiente não foram. Por isso, em PAL, Samus se move na mesma velocidade que em NTSC, mas o resto do mundo se move mais devagar. Com isso, dá para pegar as Bombs e sair da sala pouco antes de a porta travar, pulando o miniboss: https://www.youtube.com/watch?v=R3t8TIIj7IM
Na versão NTSC, o mesmo skip exige uma preparação complexa e dezenas de inputs consecutivos com precisão de frame, e até hoje apenas uma pessoa conseguiu: https://www.youtube.com/watch?v=jcKUMk5g8Wk
Também há uma comparação dos speedruns assistidos por ferramentas mais curtos em NTSC (à esquerda) e PAL (à direita): https://www.youtube.com/watch?v=KD_-thqcB5s As duas runs usam quase a mesma rota até praticamente o fim, e a versão NTSC é mais rápida em quase todas as salas, mas a preparação para execução arbitrária de código é completamente diferente, então a PAL acaba terminando primeiro. A run em NTSC precisa fazer uma sequência muito lenta de pausar/despausar para atravessar uma porta sem acioná-la, sair dos limites e causar corrupção de memória. Já a versão PAL consegue execução arbitrária de código totalmente dentro da tela explorando uma condição de corrida no sistema de animação do jogo. É uma disputa entre o temporizador de knockback dos espinhos e a animação de aterrissagem de Samus; como só o timing de Samus foi ajustado para PAL, e o dos espinhos não, em PAL surge um timing explorável apenas nesse contexto
Com a chegada do Dreamcast, pela primeira vez surgiram jogos que permitiam alternar entre 50 Hz e 60 Hz, desde que a TV suportasse. E, nos jogos que não refletiam corretamente essa diferença, também dava para voltar para 50 Hz e deixá-los mais fáceis; lembro que Crazy Taxi era bem mais fácil em 50 Hz
Parece estranho que jogos tão diferentes tenham sido vendidos assim mesmo, mas entendo completamente por que essa escolha foi feita. Quando criança, eu simplesmente presumia que Mario era Mario em qualquer lugar, e Sonic também era Sonic em qualquer lugar
Fico me perguntando se essas diferenças acabaram na era dos consoles 3D. A partir dali, renderização e lógica de jogo, em sua maior parte, já não eram totalmente amarradas uma à outra
Parece haver um erro de digitação no texto original. Ele fala em proporção de tela 8:6, mas isso é o mesmo que 4:3; pelos cálculos, o correto seria 8:7
Acho que faltou a parte em que 256x224, ou seja, a resolução de saída 8:7, é esticada para algo em torno de 4:3, mais precisamente uma imagem 64:49
A taxa de dots do SNES é de cerca de 5,37 MHz, mais lenta que a taxa de pixels quadrados de cerca de 6,13 MHz definida pelo padrão ATSC. Como ela é exatamente 8/7 mais lenta, os pixels são esticados horizontalmente por 8/7, e a resolução 8:7 é esticada para (8/7)(8/7)=64/49, ficando próxima de 64:48=4:3
O cálculo de que “para chegar a uma proporção próxima de 4:3 seriam necessários 224(4/3)=298 dots visíveis” passa a ter, considerando o fator acima, um coeficiente de (4/3)/(8/7)=7/6. Então seriam necessários 224*(7/6)=261,33... dots visíveis, muito mais perto dos 256 que foram realmente escolhidos
Eu usava uma caixa comutadora ligada à saída RF para alternar entre o SNES e a antena da TV
Mais tarde, depois que virei engenheiro de vídeo, consegui rir disso, mas, na época, foi uma sorte o meu eu criança não saber o quanto aquela qualidade de imagem era horrível
A proporção de tela 8:7 da arte também aparece em ports de SFC/SNES para outras plataformas, como ROCKMANX3 / Mega Man X3
As versões para PSX/Saturn/PC mantiveram a arte original sem esticá-la; em vez disso, para ajustar 8:7 a 4:3, adicionaram margens verticais adaptadas a cada fase. Para quem está acostumado com a versão original, isso incomoda bastante ao jogar, e nas capturas de tela da versão Saturn dá para ver que tudo parece um pouco magro demais: https://segaretro.org/Mega_Man_X3
Fico curioso para saber quanto tempo Fabien leva para escrever textos assim. Há muitos detalhes e a organização é muito limpa
Fico curioso sobre quanto da resolução do SNES é fixo no hardware do console e quanto é uma área que o cartucho poderia acionar
Por exemplo, se um cartucho tivesse seu próprio coprocessador, não precisasse carregar sprites e também tivesse um clock on-board, em teoria ele poderia exibir mais de 256 pixels horizontais em uma linha?
Com um coprocessador, ele poderia renderizar um frame por conta própria e colocá-lo na posição de memória de onde os tiles da próxima linha seriam lidos. Acho que era mais ou menos isso que o SuperFX fazia
Mas, no fim, quem realmente desenha os pixels e processa coisas como a quantidade de cores é a PPU, então o resultado final fica preso às limitações da PPU