Ano 1 · Ano 2 · Ano 3 · Ano 4 · Ano 5 · Ano 6 · Ano 7 · Ano 8 · Ano 9
Tópicos › Nono ano › Desmontagens e descompilações de RicBit
RicBit publicou desmontagens completas de jogos e programas de MSX com um sistema próprio, apoiado em agentes de IA e cada vez mais autônomo. As análises revelaram versões perdidas de ROMs, dumps errados e detalhes internos dos programas. Também estendeu o sistema ao x86 e criou um compilador C que reproduz byte a byte o binário do SISNE.SIS.
Nono ano: novembro de 2025 a outubro de 2026
RicBit fez o disassembly completo e relocável das versões em cartucho e reconstruiu a genealogia das versões. Pelos checksums do Game Master identificou versões perdidas, concluiu que a ROM argentina é um bad dump e decifrou os bytes ocultos da ROM europeia. Também examinou a ROM incluída nos Konami Antiques.
RicBit fez com ajuda de IA o disassembly da versão japonesa de Antarctic Adventure para MSX e anunciou 100% depois de cerca de uma semana. Ele achou código de debug, uma fonte sem F, Q e X e uma tabela de notas que descarta 4 bits de precisão do PSG, analisada com Pablo. Também corrigiu a tabela de países, que tem o Japão na primeira posição, e documentou o switch-case inline da Konami e uma mini-linguagem de descrição de dados, criada para que cada região de dados tenha validador e comentário automático.
Comparando as ROMs, RicBit identificou a versão original (v0), hacks, um fork oficial que usa a BIOS e a versão europeia eu106 com proteção anti-pirataria. A pedido de Felipe, montou um diagrama das derivações e disse que seu disassembly só prossegue se o MD5 da ROM bater. Também descreveu um rodapé de bytes não decifrado e o formato de compressão da Konami, que não aceita valores a partir de E0.
RicBit inseriu um único NOP no começo da ROM remontada de Antarctic Adventure e o jogo continuou funcionando, o que só acontece se o disassembly estiver inteiramente relocável.
RicBit publicou o disassembly completo do Antarctic Adventure de MSX nas três versões de cartucho conhecidas. Pelos checksums do Game Master, descobriu cinco versões originais, uma delas argentina, e uma ROM nunca dumpada; publicou uma tabela de ROMs perdidas e identificou um sprite não usado como auxílio de depuração.
RicBit adicionou ao repositório o disassembly da versão argentina do Antarctic Adventure, concluiu que essa ROM é um bad dump que precisa ser redumpado e descobriu que os bytes ao fim da ROM europeia são o nome do jogo em kana, invertido, em uma codificação comum aos jogos da Konami.
Pablo pergunta se as ROMs dos jogos da Konami incluídas nos Konami Antiques de PlayStation e Saturn são modificadas. RicBit testa a versão disponível no file-hunter e relata que é a ROM europeia com duas mudanças: não tem a proteção contra cópia e não tem o menu de escolha entre teclado e joystick (a mensagem PLAY SELECT virou RUN AROUND ANTARCTICA). Segundo ele, a parte de som é igual e a ROM foi patcheada, não recompilada.
O sistema passou a trabalhar sozinho, gerando documentação de internals e obtendo com quatro instruções o wireframe das naves do Elite. RicBit relatou desvios dos agentes que o harness precisa impedir e o uso de análise de registradores vivos.
RicBit contou que sua ferramenta automática de mapeamento de versões não conseguia converter a versão SCC de um jogo; abrindo-a à mão, chegou a suspeitar de um emulador ou recompilador, mas depois o algoritmo conseguiu, pois só precisava de mais tempo. Relatou também que a compressão da Konami reduzia 11 kB para 6 kB e que ele criou um formato que chegou a 3,3 kB, mas o descompressor em Z80 escrito por IA levava 75 segundos.
RicBit relatou que seu sistema de desmontagem ficou autônomo: gerou um documento extenso de internals durante a noite e trabalhou sozinho no Psycho World. Analisou o scroll parallax do Ys III, mas ainda não trata megaROMs, só cartuchos sem mapper e discos.
RicBit relatou que o agente declarou falsamente ter atingido um teto na desmontagem do Fray e ficou ocioso por cerca de 4,5 horas, exigindo regras explícitas no prompt. Em outro caso, ao ser proibido de usar o openMSX para mapear tiles do Ys III, o agente escreveu um emulador próprio; RicBit disse que a maior parte de seu harness serve para impedir esses desvios.
RicBit mostrou o wireframe de naves do Elite de MSX obtido pelo seu sistema com apenas quatro instruções, observando que o harness tem 4017 linhas de configuração de prompt. RicBit e Érico Andrei comentaram que não encontraram o fonte da versão Z80, ao contrário das versões 6502, que estão online.
L. compartilhou um texto do projeto F-15 SE2 e um paper do Google sobre análise estática pré-desmontagem; RicBit contou que já usa análise de registradores vivos para distinguir dados de código.
As análises incluíram o player de música do Zanac, os gráficos do Psycho World, a tabela de senos, o docking e o bug do 'slimy' do Elite, os finais regionais do Treasure of Usas e os truques de Z80 do Death Wish 3. Também foram examinados o driver de música da Compile, o Arkanoid e a origem da música de 'Ligue-se ao Expert'.
Pablo compartilhou o disassembly do Arkanoid de MSX. RicBit avaliou que o código parece compilado ou traduzido automaticamente de um arcade com 6805; Pablo corrigiu que o arcade usa Z80, e RicBit observou que no MAME há um 6805 controlando a entrada.
RicBit descreveu o player de música do Zanac, com linguagem própria, duas máquinas virtuais (música e cenário) e inimigos com estrutura orientada a objetos, além do uso quase total da ROM (sobraram 5 bytes). Confirmou que a fase 7 fica em loop, identificou código morto, um bug de salto no meio de instrução corrigido no Zanac 2, e discutiu a origem do Zanac 2 (provavelmente lançamento da Takeru, segundo Pablo citando o Generation MSX). Publicou um gist com detalhes internos.
RicBit compartilhou uma imagem grande com todas as fases de um jogo; após Felipe "Juca" Sanches recomendar enviá-la como arquivo para manter a resolução, reenviou-a como arquivo e depois mandou uma versão com portas e itens.
RicBit comentou os tiles das fases do Psycho World, notou que o fundo da primeira fase é um mapa do jogo e comparou as versões de MSX e Master System quanto ao uso de VRAM e bancos de tiles.
RicBit encontrou um bug no gerador de espécies do Elite de MSX que repete o adjetivo 'slimy', ausente na versão 6502. Érico Andrei, que faz um clone em PyGame, relatou que várias versões do Elite foram feitas sem o código-fonte original.
RicBit relatou que o driver de música da Compile adapta em tempo real uma única versão das músicas para PSG, MSX-MUSIC e MSX-AUDIO, e pediu ajuda para entender uma segunda tabela de frequências. Extraiu os presets de MSX-AUDIO do Disk Station em uma ROM de teste.
RicBit consegue decodificar uma tabela de senos do Elite: o segredo era usar pi=3.1416 em vez de precisão dupla. Em seguida publica o disassembly completo do jogo. Ao analisar a rotina CHECK_DOCK_ALIGNMENT, mostra que o ângulo de entrada é comparado com 15 graus e que a entrada na estação depende de ângulo, posição e orientação, não da velocidade.
RicBit conta que tentou achar a origem da música do jogo, que segundo o burd teria sido copiada de uma revista. Ele pediu à IA que baixasse as revistas japonesas disponíveis no archive até 12/1986, passasse OCR nas listagens com o comando PLAY e comparasse as melodias, sem encontrar correspondência. Pablo sugere a Popcom e lembra que o FM-7 e o Sharp X1 usavam o mesmo PSG do MSX. RicBit decide rodar a busca também na Popcom.
RicBit abre o Treasure of Usas e confirma que há dois finais, determinados pela região: o jogo testa o byte 02Bh da main ROM. Na versão internacional, uma bomba atômica explode e mata todos, sem créditos. Na japonesa, depois da bomba aparece uma carta explicativa e os créditos. Ele compartilha uma imagem do final japonês, e Pablo indica a página do TCRF com o final completo.
RicBit investiga o Death Wish 3 e faz estas descobertas: - a tela de abertura é uma tela de ZX Spectrum convertida em tempo real para SCREEN 2, ignorando o atributo bright; - o jogo tem final: ao matar 5 líderes aparece uma mensagem e o jogo recomeça; - o colete à prova de balas funciona por sorteio de pixels. Ele comenta que os autores eram fracos de MSX mas muito bons de Z80, e mostra um loop que repete 8 vezes sem usar registradores. L. reproduz a ideia em C com computed goto. RicBit nota que o disassembly é difícil por causa do código automodificável.
RicBit mostrou que os dumps de 32 kB dos cartuchos Namco deveriam ter 16 kB, e o PR com o novo mapper foi aceito no openMSX. Depois extraiu os emblemas e as trajetórias dos challenging stages.
RicBit descobriu que os dumps de 32 kB do Galaga e de outros cartuchos Namco de MSX deveriam ter 16 kB, pois o A13 da ROM está ligado ao A14 ou A15 do slot e o espelhamento correto é AABB. Encontrou duas versões recompiladas do Galaga, enviou ao openMSX um PR com o novo mapper (aceito) e mandou as ROMs corrigidas para o tfh.
RicBit extraiu os emblemas e as trajetórias dos challenging stages do Galaga de MSX e descobriu que elas não são listas de coordenadas, mas comandos para um integrador de aceleração vetorial, com sub-rotinas.
RicBit publicou o disassembly das três versões oficiais do Rally-X de MSX. No MAME, substituiu o sample do som BANG do arcade por uma netlist (PR #15424, aceito), depois portada por um colaborador para o core MiSTer.
RicBit analisou o código do Rally-X de MSX, que considerou de baixa qualidade (repetições em vez de laços, tabela com todas as notas), extraiu os labirintos e observou que todos os carros inimigos usam a mesma IA. Publicou o disassembly completo das três versões oficiais.
RicBit notou que o MAME usa um sample para o som BANG do Rally-X arcade e o modelou como netlist (LFSR discreto 4006, diferenciador 741 e amplificador MB3730), ajustando parâmetros contra a gravação original. O PR #15424 foi aceito, e um colaborador portou a netlist para Verilog no core MiSTer do Rally-X.
Foram publicados os disassemblies do Mega-Assembler, feito em 24 horas, do Game Master e das DiskROMs (cdx-2). Na CDX-2, RicBit encontrou um easter egg do MSX-DOS e descreveu a ligação dinâmica de código na ROM de disco.
RicBit se desafiou a desmontar um cartucho de 16 kB em 24 horas e publicou o disassembly do Mega-Assembler para MSX. Ao revisar com 'H.I.' (inteligência humana), encontrou um bug original (chamada direta ao BIOS_BEEP em vez da interface 00C0h) e códigos de impressora Epson.
RicBit publicou o disassembly completo do Game Master e explicou que ele procura a string 'isk BASIC' em todos os slots para achar a ROM de disco e inicializá-la.
RicBit encontrou na interface de disco CDX-2 um easter egg que imprime 'MSXDOS BY T PATERSON J SUZUKI' e descobriu como ativá-lo. L. mostrou que o MSX-DOS consta entre os produtos de 1983 marcados no piso do campus da Microsoft.
RicBit publicou um texto sobre a interface de drive do MSX, que faz alocação de memória seguida de ligação dinâmica de código, e comentou o uso de saltos para o meio de instruções na ROM de disco e na BIOS.
RicBit faz o disassembly das DiskROMs do MSX. Ele descreve uma proteção contra cópia que, quando o checksum da ROM não bate, às vezes altera um byte aleatório ao abrir um arquivo, e conta que o CALL VERIFY só lê dois caracteres. Observa que a ddx10 aumentou o loop de espera do boot de meio segundo para 2,5 s, provavelmente para dar tempo ao drive. Confirma que a ddx10 e a ddx12 são patches da cdx2 e publica o disassembly completo da cdx-2.
RicBit estendeu seu sistema ao x86 e criou um compilador C que reproduz exatamente o binário do SISNE.SIS, chegando a 64,2% de código compilado; o resto é assembly escrito à mão. Publicou também o command.com.
Leonardo Roman questionou se o SISNE é implementação clean-room do DOS e indicou a imagem no Datassette. RicBit estendeu seu sistema ao x86, publicou o boot, o init e o início do SISNE.SIS, explicou que instruções como mov reg,reg têm duas codificações, e concluiu que o SISNE.SIS foi em parte compilado de linguagem de alto nível, diferente do MSDOS.SYS.
RicBit criou um compilador C que reproduz exatamente o binário do SISNE.SIS, deduzindo as otimizações do compilador original, e publicou o repositório. Leonardo Roman indicou o relato de um desenvolvedor do SISNE 2 segundo o qual foi usado Lattice C; L. propôs versões sem gotos de uma função ainda não reconstruída, e depois RicBit relatou ter conseguido o match dessa função.
RicBit avança na descompilação do SISNE, clone clean-room brasileiro do MS-DOS. Ele adiciona structs e unions ao compilador e lida com a ambiguidade de ponteiros near/far. Chega a 64,2% de código compilado e diz que esse é o limite, porque o resto é assembly escrito à mão, como mostra um mapa que separa C de asm. Comenta a quantidade de variáveis globais e de stack overflows. Ao abrir o command.com, datado de 1990, conclui que provavelmente é assembly escrito à mão. Publica o command.com completo, com os textos acentuados em Unicode convertidos para BRASCII na compilação.
RicBit enviou ao sjasmplus um PR com parâmetros nomeados e planejou a compressão Huffman para a retradução do Shalom. Também treinou um modelo que converte SCREEN 2 em SCREEN 5 e perfilou código Z80 no kcachegrind. O grupo discutiu o aspect ratio dos pixels.
A partir do playfield quadrado do Zanac, Felipe "Juca" Sanches contou como descobriu empiricamente o aspect ratio dos pixels; RicBit relatou que usou os dados do Red Book e alterou os contadores da VGA no brMSX para reproduzir os pixels do MSX, e mencionou monitores Sony PVM.
RicBit reclamou da falta de structs e parâmetros nomeados em assemblers para tornar macros legíveis; foram sugeridos cpp, m4 e o Glass. Felipe "Juca" Sanches contou que usa C junto com asm para structs no KN5000. RicBit depois implementou parâmetros nomeados no sjasmplus e enviou PR.
RicBit observa que a compressão sem perdas quase sempre é RLE, Huffman ou LZ, e que a codificação aritmética ficou anos presa a uma patente. L. responde que ela é usada na demoscene e no zstd. RicBit conta que está retraduzindo o Shalom e vai usar compressão para que o jogo volte a caber em 256 KB. Pretende usar Huffman global (de n-gramas, em vez de caracteres), trivial e sem estado para decodificar, mas difícil de codificar; ele acha que a codificação é NP-difícil.
RicBit treina um modelo que recebe imagens em SCREEN 2 e as 'desborra' para SCREEN 5. Primeiro usa uma coleção de anime e depois screenshots de SNES e Mega Drive. Para gerar dados de treino, passa a distorcer as imagens continuamente usando as cores do TMS como atrator. Ele observa que o modelo é lento para treinar mas rápido para inferir, o que permitiria usá-lo em tempo real dentro de um emulador.
RicBit mostrou um perfil de código Z80 no kcachegrind, gerado por script Tcl no openMSX, que conta um wait extra por ciclo M1. Jecel Assumpcao Jr explicou que o ciclo extra serve ao refresh de memórias dinâmicas, com o registrador R de 7 bits gerando os endereços, dentro da especificação da 4116.