Mais detalhes do que você queria saber sobre como cartuchos de Game Boy funcionam

• Para criar cartuchos de Game Boy do zero, foi necessário passar por anos de pesquisa e projeto
• Este texto organiza de forma sistemática, do ponto de vista de iniciantes, as principais informações técnicas necessárias para criar um cartucho de Game Boy personalizado
• O Game Boy é uma plataforma atraente para a comunidade de desenvolvimento de jogos retrô e hacking de hardware graças à sua estrutura de hardware simples e altamente expansível
• Os cartuchos podem incorporar dados do jogo e hardware adicional (como RTC, sensores etc.), adicionando novas funções ao Game Boy
• Por meio do circuito Memory Bank Controller (MBC), é possível fazer expansão de capacidade e acesso seletivo à memória, permitindo diferentes formas de execução dos jogos

---

Introdução e objetivos

• O autor definiu como meta pessoal criar um cartucho de Game Boy completamente do zero
• Ele organizou em formato open source e publicou o conhecimento sobre a estrutura interna e o princípio de funcionamento dos cartuchos de Game Boy
• O objetivo do texto é reorganizar informações técnicas complexas a partir de uma perspectiva de iniciante, para que qualquer pessoa consiga acompanhar
• A explicação foca não no funcionamento interno do hardware, mas no comportamento (behavior) observável de fora
• A descrição toma como base o SoC do DMG (Game Boy original), mas a interface básica de cartucho é semelhante em toda a família Game Boy

O que torna a plataforma Game Boy especial

• Graças à sua simplicidade e clareza de projeto, o Game Boy facilita formar um modelo mental da estrutura de hardware e software
• Suas características de portabilidade e baixo consumo, além da ausência de proteções complexas ou trava regional, permitem que qualquer pessoa desenvolva para a plataforma
• Há um grande acúmulo de documentação técnica, esquemas de hardware e materiais produzidos pela comunidade
• A biblioteca de jogos oficiais e não oficiais é vasta, e toolchains open source e ferramentas de scripting visual seguem sendo ativamente mantidas
• Formou-se um ecossistema expansível que inclui não só drivers de hardware, mas também emuladores precisos e implementações em FPGA

Estrutura básica de um cartucho de Game Boy

• Nos consoles antigos, a fronteira entre software e hardware era pouco definida
• O Game Boy não tem sistema operacional nem armazenamento não volátil interno. Todo o código executável e qualquer hardware adicional ficam no cartucho
• Por isso, o cartucho precisa estar totalmente funcional para que o Game Boy inicialize e opere
• O conector de borda de 32 pinos na parte inferior do cartucho é a interface central de troca de sinais com o console
• Entre cartucho e console, os sinais se dividem em alimentação, controle (leitura/escrita/seleção de chip), barramento de endereços (16 bits) e barramento de dados (8 bits)

Barramentos (Bus) e princípio de funcionamento

• Um barramento é uma estrutura em que vários componentes compartilham as mesmas linhas de sinal para transmitir dados
• A CPU do Game Boy coloca o endereço desejado no barramento de endereços e os dados no barramento de dados
• Como a estrutura do barramento é paralela (parallel), há pinos físicos correspondentes a cada bit
• Isso favorece a velocidade, mas como o barramento é compartilhado, existe risco de colisão/contenda (escrita simultânea)
• Se vários ICs tentarem colocar dados na saída ao mesmo tempo, pode ocorrer curto-circuito (com risco de aquecimento e falha), então apenas um IC deve ficar ativo por vez

Principais categorias de memória no Game Boy

• O Game Boy pode ter até quatro tipos de IC de memória (RAM interna, memória de vídeo, ROM do cartucho e RAM do cartucho)
• Na prática, a memória de vídeo usa um barramento independente e costuma ficar fora das explicações gerais
• O conjunto formado por RAM interna, RAM de cartucho e ROM de cartucho compartilha o mesmo barramento de endereços e de dados
• Necessariamente, apenas um chip por vez realiza operações de leitura ou escrita no barramento de dados
• Em termos práticos, também se usa a nomenclatura RAM interna (WRAM), RAM de cartucho (SRAM), RAM de vídeo (VRAM) e RAM de alta velocidade (HRAM)

Chip Select e composição do circuito

• Cada chip de memória possui um pino de sinal de seleção de chip (CS/CE, Chip Select/Chip Enable)
• Dependendo do estado desse sinal, apenas um chip específico pode acessar o barramento de dados
• Para fazer a seleção de chip, o Game Boy reaproveita os 3 bits mais altos do barramento de endereços (A15, A14, A13) e o pino _CS da CPU
• Essa ligação garante que dois ou mais chips não fiquem ativos ao mesmo tempo
• Por exemplo, o chip de ROM só é ativado quando A15 é 0, enquanto a RAM é ativada por outra lógica

Mapa de memória (Memory Map) e a perspectiva do programador

• Os estados físicos de endereços e pinos são abstraídos, e o programador enxerga apenas o mapa lógico de memória
• No espaço de endereçamento de 16 bits, a faixa 0x0000–0x7FFF é mapeada para a ROM do cartucho, 0xA000–0xBFFF para a RAM do cartucho e 0xC000–0xDFFF para a RAM interna
• Ao acessar um endereço específico, a faixa de memória desejada é ativada automaticamente, enquanto as demais são desativadas
• Materiais de mapa de memória são referências importantes na documentação do Game Boy

Memory Bank Controller (MBC)

• O MBC é o circuito central nos cartuchos de Game Boy que permite ROMs maiores que 32 KB e a conexão de RAM adicional/periféricos
• Vários tipos de MBC foram comercializados, mas aqui a explicação usa como base o MBC5, relativamente simples e de uso geral
• O MBC5 usa a técnica de switching (banking) para suportar até 8 MB de ROM e 128 KB de RAM de cartucho
• Ele também pode controlar acesso à RAM e hardware separado como sensores externos e RTC
• Entre os pinos de endereço da ROM do cartucho, os bits superiores (A22~A14) são controlados dinamicamente pelo MBC5, enquanto os bits inferiores se conectam diretamente ao barramento de endereços do console

Princípio do ROM banking

• A CPU do Game Boy tem espaço de endereçamento máximo de 64 KB, mas na prática usa apenas 32 KB (16 KB + 16 KB) para acesso à ROM
• O MBC5 controla diretamente os endereços mais altos da ROM (seleção de banco), mapeando o trecho desejado em unidades de 16 KB para o espaço de endereçamento da CPU
• Em termos de hardware, os 14 bits inferiores (A0~A13) do barramento de endereços da CPU se conectam diretamente ao chip de ROM, e os demais vêm do MBC5
• Durante a execução do jogo, quando o software escreve um valor em um endereço de memória específico, o MBC detecta isso e atualiza internamente o valor do banco selecionado

Protocolo e mecanismo do MBC

• O MBC5 detecta combinações específicas de endereço e sinais de controle para executar tarefas como seleção de banco de ROM, seleção de banco de RAM e ativação/desativação de outras funções
• Por exemplo, quando ocorre uma escrita na faixa 0x2000~0x3FFF, correspondente a A15=0, A13=1, A14=0, o valor presente no barramento de dados é gravado como número do banco de ROM
• Para o programador, a troca de banco não é codificada como controle direto de circuito de baixo nível, mas simplesmente como gravação de dados em um endereço específico
• O uso de RAM de cartucho, sensores, RTC etc. também é controlado com padrões semelhantes
• Essa técnica de reutilização do barramento (bus reuse) reduz o número de componentes e ajuda a baixar o custo

Conclusão e uso pela comunidade

• A particularidade da estrutura dos cartuchos de Game Boy está em seu baixo custo, alta confiabilidade e expansibilidade
• Ao criar cartuchos por conta própria, é essencial ter entendimento preciso dessa estrutura e desses protocolos
• Com apoio da comunidade e da ampla documentação disponível, é possível reduzir bastante a barreira de entrada no desenvolvimento integrado de hardware e software

Referências e caminhos para estudo adicional

• O texto Game Boy/Game Boy Color Architecture, de Rodrigo Copetti
• A documentação técnica de gbdev.io e Pan Docs
• Diversos projetos open source de cartuchos e toolchains (por exemplo, GBDK, RGBDS etc.)
• Exemplo de projeto feito do zero: abc.decontextualize.com

(Na parte final do texto original, também são abordados elementos adicionais mais complexos, como variações de design de MBC, EEPROM/flash memory, ICs de entrada/saída e integração de periféricos, mas os tópicos acima correspondem ao núcleo do funcionamento dos cartuchos de Game Boy.)

[GN⁺]

Comentários do Hacker News

• Quero compartilhar minha experiência com o TXB0108 da TI. À primeira vista, por causa da detecção automática de direção, parece que não é preciso adicionar lógica de direção separada, mas na prática eu não recomendo o uso. Se houver ruído elétrico, pode acontecer de a direção se inverter e uma entrada virar saída. Nessas horas, o dispositivo às vezes aguenta bem, e em casos piores ocorre a chamada “fumaça mágica”. Se a sorte for realmente ruim, isso pode até causar acidentes em ambientes industriais. Acho que esse tipo de componente tem riscos ocultos demais para especialistas e não deveria ser tão promovido. Só deve ser usado quando se conhece exatamente o modo de falha ou não existe alternativa.

  • Esses componentes são realmente imprevisíveis. Basta haver um ou dois polegadas de trilha na saída, ou até só um conector, para o ringing na saída frequentemente provocar reversão automática de direção. É praticamente impossível de usar para quem não é especialista. Justamente nas situações em que dá vontade de usá-lo, ele acaba sendo difícil de usar.

  • Já tive a experiência de a direção ficar mudando continuamente em velocidade altíssima, gerando ruído severo e oscilação. Também há várias restrições relacionadas a pull-down, mas quando ambos os lados eram puxados na mesma direção, ainda funcionava razoavelmente bem.

• Enquanto eu procrastinava outras coisas, fiz algumas observações sobre a primeira impressão do projeto abc-pcb.pdf

  • São necessários capacitores de desacoplamento ao redor de U6 e U8. Lógica LVC consome bastante energia durante a comutação, então eles precisam ficar próximos dos gates.
  • No level translator WideBus de 16 bits, é preciso colocar um capacitor em cada pino de alimentação. Há um motivo para existirem vários pinos de alimentação.
  • A direção do barramento de saída de U6 parece estar errada. Pela minha experiência, uso quase sempre Altium e não conheço bem KiCad, então talvez não seja um problema.
  • VBUS não deve ser usado como sinal lógico quando se quer confiabilidade. Se a subida do sinal for lenta, o timing da conversão pode variar e causar comportamento estranho. Recomendo limpar o sinal com um Schmitt trigger.
  • Não há circuito de proteção ESD na porta USB. Se quiser que dure bastante, sugiro usar algo como o ECMF02-4CMX8, embora soldar possa ser um pouco chato.
  • O esquemático de Q1 não é intuitivo. Se desenhar simplesmente os dois MOSFETs de forma normal e colocar identificadores, fica muito mais fácil de ler.
  • No chip IC2 (por que IC2 e não U2?), as linhas 4, 5, 6 e 7 estão em cross-drive. Não se deve aterrar os dois lados; apenas o lado de entrada deve ir ao terra. A saída deve ficar desconectada ou então usar pull com resistor.
  • O pino SENSE de U7 quase não consome corrente, então não há necessidade de desperdiçar energia com divisor resistivo.
  • Para amortecimento da PDN (rede de distribuição de energia), talvez fosse bom adicionar um ou dois capacitores eletrolíticos de maior porte.

• Fico pensando como teria sido ótimo se esse texto existisse na época em que eu fazia cartuchos customizados.
  No meu jogo Cubeat, implementei música FM colocando um chip OPL3-L no pino de audio in do GB, e a lógica MBC usa apenas chips lógicos discretos da série 7400.
  Um dia ainda quero terminar e lançar isso; experimentar esse tipo de truque curioso no GB é realmente muito divertido.
  Informações sobre Cubeat

• Era exatamente nesse nível de detalhe que eu queria entender a estrutura dos cartuchos de Game Boy.

• A ideia de os cartuchos de Game Boy fornecerem RAM e espaço em disco junto com o app é interessante; pensando bem, isso também faz sentido do ponto de vista lógico.
  Às vezes imagino que, se os celulares funcionassem assim, talvez fosse possível fazer upgrade comprando novos cartuchos para rodar apps mais pesados sempre que a tecnologia dos chips melhorasse a cada poucos anos, ou até encaixar uma nova antena.

  • Celulares modulares já foram propostos há muito tempo, mas nunca foram práticos nem úteis. Se todos os componentes forem conectados por soquetes, a latência entre chips aumenta e a confiabilidade cai. Isso é ainda pior num produto que fica balançando no bolso o dia inteiro.
    Na prática, não é só uma coisa do celular que fica obsoleta: câmera, tela, CPU, RAM, bateria e quase todo o resto acabam pedindo upgrade ao mesmo tempo. Nesse caso, faz mais sentido comprar um celular novo do que trocar partes separadas. No fim, o principal ganho de trocar peças individualmente seria economizar o preço da carcaça.

  • Estou discutindo um sistema de hot patch de ROM para microcontroladores, e por esse motivo a vantagem de uma estrutura em que todo o app fica gravado no chip e roda imediatamente é bem clara. Só que, conforme as exigências dos usuários mudam cada vez mais, tudo parece ficar mais complexo.

  • Com certeza é uma boa ideia, mas fico pensando se o desempenho do hardware do aparelho onde se encaixa isso não acabaria sendo o limite.
    Dá para colocar RAM mais rápida no cartucho, mas é duvidoso que a placa existente consiga realmente aproveitar isso.
    Mesmo que fosse possível adicionar armazenamento mais rápido, se o hardware de suporte continuar o mesmo, não está claro quanto efeito prático isso teria.

  • Cheguei até a imaginar encaixar uma câmera também.

• Sobre a afirmação de que, ao desenvolver software customizado para Game Boy, não é necessário contornar hardware de proteção contra cópia ou trava de região, alguém perguntou se na prática ainda não seria preciso passar na verificação do logo.

  • A explicação provavelmente é que isso quer dizer que não é preciso modificar nem hackear o hardware, bastando incluir um certo blob específico no cabeçalho da ROM. Ao usar a toolchain RGBDS (RGBFIX), isso pode ser inserido automaticamente.
    E, depois da decisão Sega v. Accolade, esse tipo de verificação de título na prática já não é mais legalmente obrigatório, então não existe uma barreira real de contorno.

• É uma pena que o devrs.com, que era um site de referência sobre desenvolvimento para GB que eu costumava visitar, não esteja mais no ar. A maioria dos links já morreu, mas era um lugar com muitos projetos inspiradores.

• O vídeo da palestra Ultimate Game Boy Talk (apresentação da 33c3) também vale a pena.
  Ultimate Game Boy Talk - 33c3

• Minha cópia de Pokemon Blue passou por uma lavadora e até por uma secadora há 20 anos, e ainda funciona normalmente. É um hardware realmente muito resistente. Fico curioso se um cartão SD aguentaria esse tipo de abuso.

  • Acho que o calor da secadora teria sido um problema maior do que a água.

• Neste mês comecei a mexer com KiCad e design de PCB por diversão. Fiquei curioso se existe algum caso em que alguém recriou toda a PCB do Game Boy original e depois publicou isso como open source.

  • Uma empresa chamada FunnyPlaying fabrica e vende PCBs de GBC e GBA. Versões open source são difíceis de encontrar.
    No GitHub da nataliethenerd há o projeto de engenharia reversa do CGB, mas a licença é não comercial.
    A descrição diz: "Usando a placa CGB-CPU-04, foi feito escaneamento, lixamento e reescrita para organizar o esquemático do CGB; para os valores etc., foi usado o circuito original como referência".

  • Também fiquei curioso por recomendações de materiais úteis como referência para projeto de PCB.