Análise interna dos cartuchos do Super Nintendo
(fabiensanglard.net)- Os cartuchos do Super Nintendo não eram apenas mídia de armazenamento, mas hardware que expandia as capacidades do console ao incluir proteção contra cópia CIC, SRAM e processadores auxiliares
- A capacidade da ROM era divulgada na época em bits, e entre os 3.378 títulos analisados, Star Ocean e Tales of Phantasia tinham 48Mb, enquanto Super Mario World tinha 4Mb
- A função de salvamento dependia de SRAM mantida por bateria, e há casos como a PCB de Zelda III que também incluía o decodificador de endereços MAD-1 para controlar o acesso à ROM/RAM
- Ao todo, 13 tipos de chips auxiliares foram usados em 72 jogos, assumindo no lado do cartucho tarefas como aceleração de CPU, processamento de sprites, descompressão, operações matemáticas e rasterização de polígonos
- Esses chips ampliaram muito a expressividade dos jogos da época, mas também deixaram um longo legado de engenharia reversa para a implementação em emuladores, como no caso em que foi necessário usar pacotes gráficos por não se conhecer a estrutura interna do S-DD1
Configuração básica do cartucho: CIC, ROM, SRAM
- Os cartuchos do Super Nintendo podiam conter não só instruções e assets em chips ROM, mas também chip de proteção contra cópia CIC, SRAM e até processadores auxiliares
- O CIC funcionava por meio de comunicação em lockstep entre o chip do console e o chip do cartucho
- Se o CIC do console detectasse um estado anormal, ele resetava todos os processadores
- Nem todos os cartuchos de SNES tinham CIC, e o jogo não oficial Super 3D Noah's Ark não possui CIC
- Em Super 3D Noah's Ark, é preciso primeiro inserir o jogo no console e depois encaixar um cartucho oficial por cima, e o lado de Noah's repassa as linhas de barramento usando o CIC do jogo oficial
- A capacidade da ROM era indicada na época em bits, e não em bytes
- Zelda III foi promovido como uma ROM de 8Mb, e não de 1.048.576 bytes
- A lista analisada inclui 3.378 títulos das regiões USA/Japan/Europe
- Star Ocean e Tales of Phantasia estavam entre os maiores, com 48Mb, ou 6.291.456 bytes
- Super Mario World usa uma ROM de 4Mb, ou 524.288 bytes
- Alguns títulos com função de salvamento usavam SRAM alimentada por bateria
- Quando o console era desligado, a SRAM entrava em modo de baixo consumo para reduzir o gasto de energia
- A PCB de Zelda III contém o CIC U4 (D413A), a ROM U1 de 0x80000 (524.288 bytes), a SRAM U2 LH5268AF-10TLL de 64Kbit (8KiB) e o decodificador de endereços de memória MAD-1 em U3
Alcance dos chips auxiliares e o SA-1
- O processador auxiliar mais famoso é o Super FX, usado em Star Fox em 1993, mas antes dele já existia o chip EC
- No total, 13 tipos de EC foram usados em 72 jogos
- A lista completa está organizada na wikipedia e em snescentral.com
- O SA-1, ou Super Accelerator 1, é um dos chips auxiliares mais representativos, presente em 34 cartuchos
- Ele usa a mesma CPU 65C816 do console SNES, mas roda 4 vezes mais rápido, a 10,74MHz
- Inclui 2KiB de SRAM e CIC integrado
- A PCB de Super Mario RPG não tem CIC separado; o SA-1 está em U3, a ROM em U1, e em U2 há SRAM com decodificador integrado
- O SA-1 opera sem oscilador próprio, recebendo o System Master clock pela porta do cartucho e dividindo internamente 21.4772700MHz / 2 = 10,74MHz
- O SA-1 começa em estado de stop, e a CPU do SNES cria o Reset Vector e retoma o SA-1
- O Instruction Pointer inicial do SA-1 é obtido de um Reset Vector dedicado
- Há três modos de operação: Accelerator, Parallel Processing e Mixed Processing
- Na configuração mais potente, a CPU SA-1 e a CPU do Super NES operam simultaneamente, elevando o desempenho do Super Accelerator System para 5 vezes o do Super NES original
- O ganho de processamento foi usado para animação e detecção de colisão de todos os 128 sprites oferecidos pela PPU, além de rotação e escala em tempo real dos sprites antes de gravá-los na VRAM da PPU
- O cartucho de demonstração Nintendo SA-1 mostra essas melhorias
- A comunidade de jogos retrô reduziu slowdown em jogos antigos com projetos como Eliminating slowdown in Super Mario World, Gradius III slowdown removal e Contra III slowdown removal
- Converter um título para SA-1 parece bastante complexo, especialmente porque exige remapeamento de acesso a RAM/ROM, o que também levanta dúvidas diante da documentação do SA-1 afirmar que “SNES e SA-1 usam o mesmo mapeamento de memória”
- Em 2019, o SA-1 Collection Project seguia tentando remapear automaticamente mais jogos de SNES para adaptá-los ao SA-1
Chips auxiliares de gráficos, compressão e matemática
- O CX4 é um chip da Capcom usado em Mega Man X2 e Mega Man X3
- Ele consegue processar renderização 3D em wireframe, várias operações matemáticas e gravação em VRAM após escalonamento e rotação de sprites
- Há exemplos na intro e na luta contra chefe de MMX2
- Além de wireframe, o CX4 oferece sprite functions, propulsion, vector, triangle, trigonometric functions, result tables e coordinate transform functions, e em MMX2 e MMX3 processa todos os sprites
- A PCB de Mega Man X2 tem o CIC em U4, ROM de 8M em U1, ROM adicional em U2, o CX4 em U3 e um oscilador de 20MHz em X1
- O S-DD1 é um chip de descompressão de sprites que pode fornecer dados diretamente à VRAM da PPU
- Foi usado em apenas dois jogos: Star Ocean e Street Fighter Alpha 2
- Havia o rumor de que a tela em branco antes do início do round em Street Fighter Alpha 2 era causada pelo S-DD1, mas segundo a explicação do Modern Vintage Gamer, o problema real estava na transferência de samples de áudio para a RAM do DSP
- A PCB de Street Fighter Alpha 2 tem a ROM U1 de 4MiB e o S-DD1, que descompacta assets em tempo real; o CIC é integrado ao S-DD1, então não há chip separado
- O DSP-1 responde por 16 dos 19 títulos compatíveis com a família DSP e foi usado em Super Mario Kart e Pilotwings
- O DSP do nome significa Digital Signal Processor, mas considera-se que o nome foi mal escolhido porque ele não processa sinais contínuos como um DSP típico
- Segundo o manual do desenvolvedor, o DSP-1 opera em blocking mode, fazendo a CPU do Super NES esperar enquanto o DSP processa os dados
- Ele oferece instruções para multiplicação rápida de 16 bits, recíproco, projeção sin/cos, tamanho de vetor e rotação, sendo importante para programação com HDMA e atualização da visão 3D no Mode 7
- A PCB de Super Mario Kart tem CIC externo, ROM, SRAM para salvamento, decodificador de endereços MAD-1, bateria e um oscilador para operação a 8MHz
- As três versões DSP-1, DSP-1a e DSP-1b trouxeram correções de bugs e melhorias de processo, mas com pequenas diferenças de comportamento que fizeram o avião colidir com o chão na demo de Pilotwings
- Outros chips menores também foram usados de forma limitada em jogos específicos
- O DSP-2 foi usado em apenas um jogo, Dungeon Master, para converter rotinas do Atari ST, e parece ter servido principalmente para ajudar no escalonamento de sprites
- O DSP-3 foi usado apenas em SD Gundam GX
- O DSP-4 foi usado em Top Gear 3000 e The Planet's Champ TG 3000
- O OBC-1 foi usado apenas em Metal Combat: Falcon's Revenge; havia rumores de que servia para manipulação de sprites, mas isso é discutido em nesdev.org
- O S-RTC é um chip que rastreia relógio em tempo real em Daikaijuu Monogatari II, e não está claro por que um desenvolvedor da Hudson Soft considerou necessário esse rastreamento
- O SPC7110 da Epson é um chip de descompressão de dados usado em Tengai Makyou Zero, Momotaro Dentetsu Happy e Super Power League 4, e em Super Power League 4 também há função de relógio em tempo real
- A linha ST da SETA Corporation teria sido projetada para melhorar a IA dos jogos; o ST-010 foi usado só em Exhaust Heat 2, o ST-011 só em Hayazashi Nidan: Morita Shougi, e o ST-018 só em Hayazashi Nidan Morita Shougi 2
- O ST-018 parece ser uma CPU ARM com instruções armazenadas em ROM interna
Família Super FX e modificações da comunidade
- O GSU-1 foi usado em cinco jogos: Star Fox, Stunt Race FX, Vortex, Dirt Racer e Dirt Trax FX
- Está entre os chips auxiliares mais bem documentados, com material em wiki, tutoriais e no Super Nintendo Developer Manual Book II
- Opera a 10,74MHz, dividindo internamente o master clock de 21,47MHz pela metade
- Graças ao cache interno de instruções de 512 bytes, ele consegue operar sem sufocar a CPU do SNES
- Quando termina seu trabalho, pode disparar uma interrupção para a CPU do console, a C-CPU
- Enquanto a PPU1/PPU2 do SNES é orientada a tilemaps e sprites, o Super FX se destaca em renderização por pixel e rasterização de polígonos
- Em geral, ele renderiza em um framebuffer presente no cartucho
- O conteúdo do framebuffer é transferido para a VRAM durante o VSYNC
- A PCB de Star Fox tem o GSU-1 em U3, o CIC em U5, o 74LS139 em U4 e a ROM em U1; em U2 há 32KiB de SRAM sem bateria
- Essa SRAM não é para savegame, mas usada em parte para armazenar o framebuffer do Super FX
- Assim como ocorreu com o SA-1, a comunidade de SNES também investe tempo no GSU-1, buscando melhorar ao máximo títulos antigos com projetos como Project Super FX
- O GSU-2 é um GSU-1 que opera na velocidade total de 21,47MHz e foi usado em apenas três jogos: Super Mario World 2: Yoshi's Island, DOOM e Winter Gold
- Há experimentos da comunidade mostrando ganho de desempenho ao trocar o GSU-1 do cartucho de Star Fox por um GSU-2
- Randy Linden, responsável por DOOM no SNES, fez toda a engenharia reversa sem documentação do chip GSU e sem código-fonte de DOOM
- A versão de DOOM para SNES foi a única porta de console capaz de usar os níveis do PC; os outros consoles precisaram simplificar a geometria
- Yoshi's Island usa principalmente o GSU-2 para escalonar e esticar sprites, gravando depois os sprites manipulados de volta na VRAM da PPU
- A PCB de Yoshi's Island tem bateria, então a SRAM é usada tanto para framebuffer quanto para estado de salvamento
- DOOM teve overclock para 32MHz, elevando o frame rate de 10–11fps para 14–15fps
- O MSU-1 não é um chip que tenha sido incluído em cartuchos lançados comercialmente
- Foi projetado por Near para permitir streaming de áudio com qualidade de CD, reprodução de FMV e acesso a até 4GB de RAM no SNES
- O alvo é a comunidade de modding de jogos, e os resultados podem ser vistos em Enhanced Zelda III: A link to the past e Enhanced Another World
O peso deixado para a implementação em emuladores
- Os chips auxiliares melhoraram muito a experiência do jogador e reduziram custos para as publishers, mas depois se tornaram um desafio difícil para desenvolvedores de emuladores
- Alguns jogos que dependiam de ECs incomuns só foram emulados corretamente em 2012
- No início, como a estrutura interna do S-DD1 era desconhecida, jogos como Street Fighter Alpha 2 eram “emulados” exigindo pacotes gráficos de sprites previamente descomprimidos
- Implementar esses chips exigiu um volume considerável de engenharia reversa
- Alguns chips tinham funções hardcoded, exigindo de-capping
- Chips que armazenavam instruções em ROM interna, como os baseados em ARM, exigem que o emulador receba arquivos de BIOS
- Mesmo em 2020, a emulação de alguns dos chips mais raros ainda não havia sido concluída
1 comentários
Comentários no Hacker News
Acho muito legal que os cartuchos dos consoles antigos fossem praticamente iguais a placas de expansão PCI de PC
Eles se conectavam diretamente ao barramento e, na prática, podiam fazer quase qualquer coisa, mas infelizmente essa prática acabou depois do GameBoy Advance, e a partir do Nintendo DS eles passaram a ser mais próximos de dispositivos puros de armazenamento de dados
Por isso hoje em dia também são possíveis expansões modernas bizarras, como um chip de ray tracinghttps://www.youtube.com/watch?v=2jee4tlakqo, e também o chip de expansão MSU1, que aparentemente não existe como chip físico real e só em emuladores de software
Em teoria seria possível fabricá-lo, então também daria para fazer um cartucho real de SNES de Road Blasterhttps://www.youtube.com/watch?v=BvIXUOr4yxU
No próprio texto, “Street Fighter Zero 2” aparece na lista como ROM dos EUA, mas Street Fighter Zero era o nome usado no Japão para Street Fighter Alpha, então Zero 2 deveria ser a versão japonesa de Alpha 2
Nela, coisas estranhas acontecem quando você substitui o cartucho por um computador moderno. Por exemplo, fazer no NES uma apresentação praticamente em PowerPoint sobre humor
https://www.youtube.com/watch?v=ar9WRwCiSr0
Então havia uma capacidade limitada de adicionar funções, e embora não fosse tão interessante quanto uma CPU extra, também não é como se houvesse tantos casos no GBA fazendo algo tão extraordinário
Queria saber se isso foi planejado para um caso de uso específico ou se havia um canal separado para componentes de expansão limitados no cartucho
Outro detalhe que ficou de fora aqui é que mesmo cartuchos sem chip de expansão tinham classes de desempenho diferentes
A CPU do SNES nominalmente rodava a 3,58MHz, mas para realmente operar nessa velocidade precisava ter um cartucho “FastROM” inserido. A Nintendo também oferecia aos publishers o formato “SlowROM”, mais barato, e nesse caso a CPU caía para 2,68MHz
Existe até uma comunidade de modders desenvolvendo patches para converter jogos SlowROM em FastROM e reduzir latência. Já li que alguns jogos SlowROM parecem ter sido originalmente desenvolvidos para FastROM e só mudaram para SlowROM no fim por exigência de corte de custos do publisher
Se a memória não falha, alegaram que nesse caso usar SlowROM economizava incríveis 50 centavos por cartucho
O concorrente TurboGrafx-16 normalmente rodava a 7MHz e usava uma CPU da família 6502 com exigências parecidas de temporização de memória, então sempre achei confuso por que o SNES era tão mesquinho com velocidade
Ainda assim, o TurboGrafx fracassou no Ocidente e o SNES foi um sucesso mundial, então alguma coisa ele fez certo
Afinal, todos os cartuchos de SNES usavam mask ROM
Eu gostaria que os desenvolvedores continuassem escrevendo esses detalhes em formato de texto em blogs, em vez de transformá-los em vlog no YouTube
Dá para colocar muitos detalhes em poucos KB
“Super Mario World” continua sendo um dos maiores clássicos de todos os tempos. Personagens, sprites e fases incríveis em apenas 360KB
Só chega a cerca de 360KB quando comprimido em ZIP
Música incrível, controles precisos e gráficos encantadores, ele acertou tudo que um jogo de plataforma precisa fazer
Terranigma está quase no mesmo nível e, para mim, Super Mario World provavelmente fica em terceiro
Texto pode ser raspado, ter algumas palavras trocadas e depois ser reutilizado em sites de SEO cheios de anúncios
Fico imaginando o que daria para fazer hoje usando a capacidade de colocar “chips de expansão” em cartuchos
Dizem que o SuperFX tem seu próprio framebuffer e copia tudo para a VRAM
Então, tecnicamente, seria possível colocar um SoC absurdamente poderoso dentro do cartucho, usar isso para renderizar gráficos modernos na resolução do SNES e depois copiar os frames resultantes para a VRAM do SNES?
Queria entender onde está o limite
A parte de que “Randy Linden, autor de DOOM para SNES, não teve acesso nem à documentação do chip GSU nem ao código-fonte de DOOM; ele fez tudo por engenharia reversa” é tecnicamente impressionante, mas fico curioso sobre por que isso precisou ser assim
Randy Linden, o único programador do port, ficou fascinado pelo jogo e inicialmente começou por conta própria a portar Doom para o Super NES
Como o código-fonte de Doom ainda não havia sido publicado na época, Linden consultou o Unofficial Doom Specs para entender em detalhe a estrutura dos lumps do jogo. Os recursos foram extraídos do IWAD, mas alguns não foram usados por limitações técnicas
Segundo entrevistas, como faltava um sistema de desenvolvimento para o Super FX, Linden criou antes um conjunto de ferramentas no seu Amiga chamado ACCESS, com montador, linker e depurador, antes de começar de fato o desenvolvimento do port
Como kit de hardware, ele conectou ao console um cartucho de Star Fox hackeado e dois controles de Super NES modificados, ligados à porta paralela do Amiga, e usou um protocolo serial para conectar mais dois dispositivos
Depois de criar um protótipo completo, mostrou-o à sua empregadora, a Sculptured Software, e a empresa ajudou a concluir o desenvolvimento. Linden disse que gostaria de ter incluído os níveis ausentes, mas o jogo já tinha atingido o tamanho máximo de um jogo com Super FX 2, 16 megabits, cerca de 2 MB, e sobravam apenas uns 16 bytes de espaço
Ele também adicionou suporte à light gun Super Scope, ao mouse de Super NES e ao modem XBAND para multiplayer. O colega programador John Coffey, fã da série Doom, modificou fases, mas algumas delas foram rejeitadas pela id Software
Sempre há uma história incrível em torno dessas coisas, e escrevi um pouco mais sobre isso aqui também: https://eludevisibility.org/super-noahs-ark-3d-source-code
Se me lembro bem, a equipe de Crash Bandicoot também estava trabalhando sem SDK e acabou descobrindo um bug de hardware relacionado ao salvamento em memory card por causa do próprio código
Fico curioso sobre de onde vieram as contagens de bytes de vários jogos
Os jogos estavam em chips ROM e, como seria de se esperar de chips ROM, os tamanhos eram potências de 2. Por exemplo, Super Mario World foi lançado em uma ROM de 512 kb, então de onde vem o número 346.330 bytes? É o tamanho comprimido?
Acho que vou precisar escrever um programa para descompactar cada ZIP e contar o padding de bytes zero no fim do arquivo
Hoje já está muito tarde; vou escrever isso amanhã e atualizar o texto
SMW.SMCcom gzip, sai um arquivo de 347 KB. Isso é bem enganosoHá outros problemas também. O texto dá a entender que o MVG descobriu que as travadas em SFA2 eram por causa do carregamento de dados de áudio, mas isso já era conhecido muito antes daquele vídeo: https://forums.nesdev.org/viewtopic.php?p=70474#p70474
Também parece haver bastante confusão sobre RTC. É bastante óbvio, como nos jogos de Pokémon de GBC/GBA, que a ideia é fazer o relógio continuar andando mesmo com o console desligado e o cartucho removido, mas o texto fala como se pudesse ser por causa de drift do clock NTSC. Não faço ideia do que isso quer dizer
Em relação à parte “Super Mario World também recebeu esse tratamento. Não me lembro de lentidão, mas eu tinha só doze anos na época”, Yoshi’s Island 4 tem lentidão em certas condições
Acontece se você estiver montado no Yoshi, pegar uma Starman e apertar um P-Switch; há também outra fase de que não me lembro exatamente, acho que era em Chocolate Island, onde muitos Monty Moles saltam ao mesmo tempo
Acho que havia um terceiro caso em que apareciam na tela ao mesmo tempo dois Sumo Bros. e um Amazing Flying Hammer Bro.
Nunca entendi bem como ROMs para emuladores são dumpadas a partir de cartuchos
Entendo a parte de extrair instruções e assets e empacotar isso num arquivo de dados que o emulador consegue interpretar. Mas como o emulador modela todo o hardware de chips de expansão que existe dentro do cartucho? Como isso é dumpado a partir do cartucho original?
Pessoalmente, eu diria que a situação no NES, predecessor do SNES, era até um pouco pior
O NES tinha muitos chips de expansão chamados mappers. A função mais comum deles não era adicionar processadores extras ou novas capacidades, mas expandir o espaço de memória do NES; como sem eles o console ficaria limitado a 32 KB de PRG ROM e 4 KB ou 8 KB de ROM gráfica CHR, eles acabaram presentes na maioria dos jogos
A maior parte dos jogos lançados depois do início de vida do NES usava esses chips
Todos eles também precisaram ser alvo de engenharia reversa, junto com o próprio console. Felizmente, isso era muito mais simples do que fazer engenharia reversa de CPUs extras ou aceleradores
Há chips comuns, usados em muitos jogos, como MMC1 e MMC3, e outros como o MMC2, que na prática era quase exclusivo de Punch-Out
Não existem tantos tipos assim de chips de expansão, então não chega a ser algo inviável de lidar
A forma de proteção contra cópia do SNES era facilmente contornada do ponto de vista do consumidor. Mas talvez não fosse do ponto de vista das desenvolvedoras ou publicadoras de jogos
Na época, todo mundo tinha um “dispositivo de backup” para SNES. Era um aparelho que se encaixava no SNES e vinha com drive de disquete, e os jogos eram “copiados em backup” para disquetes de 3,5 polegadas bem baratos
Tudo o que o sistema precisava para funcionar era de um único cartucho original, e, ao conectá-lo ao copiador, o aparelho reutilizava o chip CIC daquele cartucho
https://en.wikipedia.org/wiki/Game_backup_device
Ao ler que “o DSP-1 teve três versões: DSP-1, DSP-1a e DSP-1b. Com correções de bugs e melhorias no processo de fabricação, o comportamento do chip mudou ligeiramente, e como resultado o avião da demo de Pilot Wings caiu no chão”, percebi que preciso usar essa desculpa quando alguém perguntar por que sou tão ruim assim