Tópicos › Desmontagens de software MSX e emuladores em 4 KB
51 conversas · anos 9 do grupo

O tópico aparece apenas no ano 9 do grupo (novembro de 2025 a outubro de 2026), e quase todo o trabalho foi de RicBit, que usou um sistema de desmontagem assistido por IA. Ele começou pelo Antarctic Adventure de MSX: fez o disassembly da versão japonesa em cerca de uma semana e provou que ele era inteiramente relocável ao inserir um NOP no começo da ROM sem quebrar o jogo. Também reconstruiu a genealogia das versões (original v0, hacks, um fork oficial que usa a BIOS e a europeia eu106, com proteção anti-pirataria) e publicou o disassembly das três versões de cartucho. Pelos checksums do Game Master, identificou versões perdidas e uma ROM nunca dumpada. Mais tarde concluiu que a ROM argentina é um bad dump e decifrou os bytes ocultos da ROM europeia, que são o nome do jogo em kana, invertido. No mesmo período foram analisados o Zanac (player de música com linguagem própria, duas máquinas virtuais e um bug de salto corrigido no Zanac 2), o Psycho World e o Arkanoid, cujo disassembly foi compartilhado por Pablo Vasques Bravo-Villalba. Na mesma época, RicBit implementou parâmetros nomeados no sjasmplus e enviou PR. Também relatou que o sistema ficou autônomo e que a maior parte do harness serve para impedir desvios dos agentes, como declarar falsamente um teto na desmontagem do Fray ou escrever um emulador próprio para mapear os tiles do Ys III.
Na sequência, RicBit publicou os disassemblies do Mega-Assembler (feito em 24 horas, com um bug original na chamada ao BEEP), do Game Master, das três versões oficiais do Rally-X e, depois, das DiskROMs (cdx-2). Na CDX-2 achou um easter egg do MSX-DOS e, nas DiskROMs, uma proteção que, quando o checksum da ROM não bate, às vezes altera um byte aleatório ao abrir um arquivo. Ele também confirmou que a ddx10 e a ddx12 são patches da cdx-2. No MAME, substituiu o sample do som BANG do Rally-X arcade por uma netlist (PR #15424, aceito), que um colaborador depois portou para o core MiSTer. No Galaga, mostrou que os dumps de 32 kB dos cartuchos Namco deveriam ter 16 kB: o PR com o novo mapper foi aceito no openMSX, e as ROMs corrigidas foram enviadas ao tfh. Ainda no Galaga, extraiu as trajetórias dos challenging stages, que são comandos para um integrador de aceleração. Do Elite, obteve o wireframe das naves com quatro instruções ao sistema, achou o bug do adjetivo 'slimy', decodificou a tabela de senos e publicou o disassembly completo, com análise da rotina de docking. Também examinou o driver de música da Compile, os dois finais regionais do Treasure of Usas e os truques de Z80 do Death Wish 3, além de procurar, por OCR de revistas japonesas, a origem da música de 'Ligue-se ao Expert', sem encontrar correspondência nas revistas pesquisadas.
Em paralelo, RicBit estendeu o sistema ao x86 para estudar o SISNE, clone brasileiro do MS-DOS, a partir da imagem indicada por Leonardo Roman. Criou um compilador C que reproduz o SISNE.SIS byte a byte, ao qual adicionou structs e unions, e chegou a 64,2% de código compilado; segundo ele, esse é o limite, porque o resto é assembly escrito à mão. Publicou também o command.com, de 1990. Nas técnicas e ferramentas, ele planejou compressão Huffman de n-gramas para a retradução do Shalom e treinou uma rede que converte imagens de SCREEN 2 para SCREEN 5. Também perfilou código Z80 no kcachegrind; sobre o wait state do M1 que aparece no perfil, Jecel Assumpcao Jr explicou que ele serve ao refresh das memórias dinâmicas.
Na parte final do ano, o foco passou para emuladores em 4 KB. O msxzin, emulador de MSX em código 8086 para DOSBox, ganhou Z80 com opcodes não documentados, SCREENs 0 a 3, PSG via SCC, disco, fita e mappers megarom. Para reduzir o tamanho, RicBit criou o assembler auto-otimizador Namagiri. A versão final do msxzin saiu em 06/09, e o código-fonte foi publicado no GitHub depois que a sintaxe da Namagiri foi congelada; Felipe "Juca" Sanches havia perguntado pela publicação, citando o interesse de desenvolvedores do MAME. O minigb, emulador de Game Boy em 4 KB feito em 24 horas, chegou a 100% das ROMs dos romsets de RicBit. Com sugestões de Shideravan, passou a ser verificado contra o No-Intro e ganhou relatórios de compatibilidade de DMG e GBC; versões sucessivas passaram a rodar o Super Mario Land 2, o Asterix e o bootleg Rockman 8, ficando pendente refazer os testes de regressão. A Namagiri foi portada de C++ para Rust por 19 agentes em 2 horas, com os 512 testes passando. Por fim, RicBit portou o Galaga para o V9990, com versão jogável na web, mostrou o andamento dos gráficos do Death Wish 3 refeitos à mão com ajuda de uma rede neural, fez a abertura do Ys III com parallax em velocidade total e traduziu o jogo para japonês, inglês e português. Também planejou medir o V9990 em um turbo R real e, ao testar o Ys III nessa máquina, encontrou um defeito nos slots, que suspeitou ser da fonte.
Ano a ano: Ano 9
RicBit publicou disassemblies de jogos e programas de MSX (Antarctic Adventure, Rally-X, Elite, Mega-Assembler, Game Master, DiskROMs cdx-2), teve PRs aceitos no MAME (netlist do BANG do Rally-X) e no openMSX (mapper Namco do Galaga) e criou um compilador C que reproduz o SISNE.SIS byte a byte, com 64,2% do código compilado. Na segunda metade do ano, criou os emuladores msxzin e minigb em 4 KB com o otimizador Namagiri, portou o Galaga para o V9990 e trabalhou nos gráficos do Death Wish 3 e na abertura do Ys III para esse chip.
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.
O emulador em código 8086 ganhou Z80 com opcodes não documentados, SCREENs 0 a 3, PSG via SCC, disco, fita e mappers sem passar de 4 KB. O código-fonte foi publicado depois de congelada a sintaxe da namagiri.
RicBit desenvolve um emulador de MSX em 4 KB, em código 8086 que roda no DOSBox. A cada versão acrescenta funcionalidades sem passar dos 4 KB: - Z80 com IM0/1/2 e opcodes não documentados; - SCREENs 0 a 3, sprites e colisão; - PSG via SCC; - slots, disco e fita cassete; - mappers megarom, incluindo o do R-Type. Para reduzir o código, usa algoritmo genético e simulated annealing e depois cria a 'Namagiri', um assembler auto-otimizador que passou por algoritmo genético, LNS e GOMEA. Publica a história do projeto e, em 06/09, a versão final com o nome msxzin.
Felipe pergunta se RicBit pretende publicar os nanoemuladores, porque desenvolvedores do MAME se interessaram. RicBit indica o release online do msxzin. Depois de congelar a sintaxe da Namagiri, publica o código-fonte do msxzin no GitHub. Ele diz que a Namagiri tem 20 mil linhas, metade das 40 mil que tinha antes da limpeza da sintaxe.
Feito em 24 horas, o minigb chegou a 100% das ROMs dos romsets de RicBit; para otimizá-lo, ele criou o 'milibit'. Foi depois verificado contra o No-Intro e passou a rodar Super Mario Land 2, Asterix e Rockman 8.
RicBit faz em 24 horas um emulador de Game Boy em 4 KB. Experimenta suporte a Super Game Boy, mas o abandona para focar no DMG e diz que precisa ser cycle-accurate para passar de 90%. A compatibilidade sobe para 97,7% e 98,18% e depois chega a 100% das ROMs dos seus romsets, que ele amplia em seguida. Passam a rodar casos difíceis como Pinball Fantasies, Zerd no Densetsu, Road Rash, mappers Wisdom Tree e Berlitz e multicarts. Para otimizar, cria o 'milibit' (na prática 1/65536 de bit), medido no estágio de compressão aritmética do seu compressor. Com ele, a Namagiri ganha um gradiente mais fino e converge muito mais rápido, sem precisar rodar na nuvem.
Shideravan recomendou verificar as ROMs de teste com os checksums do No-Intro via clrmamepro, para descartar bad dumps. RicBit descobriu que o Super Mario Land 2, que usa a SRAM como pilha, não rodava, e usou a namagiri (com VND na nuvem e depois GOMEA) para liberar os 80 bytes necessários. Publicou uma versão de 4 KB que roda o jogo e, depois, outra que se recusa corretamente a rodar ROMs exclusivas de GBC.
O Asterix parou de rodar depois da inclusão do mapper da Wisdom Tree, e faltavam 8 bytes para corrigi-lo. RicBit descobriu que acrescentar alguns bytes aleatórios diminuía o tamanho do arquivo comprimido e publicou uma versão de 4 KB que roda o Asterix. Shideravan sugeriu medir a compatibilidade contra o fullset do No-Intro. RicBit disse que o fullset de DMG roda inteiro e que as dúvidas estão nas ROMs de GBC, como o Daikatana, cujo cabeçalho declara suporte ao DMG mas que é exclusivo de GBC, e o bootleg Matel Gear II, que segundo o BootlegGames Wiki não deveria rodar.
RicBit publicou relatórios de compatibilidade do minigb com os conjuntos No-Intro de DMG e de GBC. Discutiram ROMs que não são jogos (como a da scooter Aprilia, que depende de hardware extra) e o bootleg taiwanês Rockman 8, cujo mapper, segundo Shideravan, só o hhugboy suporta entre os emuladores que ele conhece. Depois de golf manual, da namagiri e de edição direta do stream LZ, RicBit publicou uma versão de 4 KB que roda o Rockman 8 e disse que ainda precisava repetir os testes de todas as ROMs para checar regressões.
Depois do Rockman 8, discutiram os próximos passos: buscar tamanhos abaixo de 4 KB ou repetir o desafio em outras plataformas. RicBit considerou o NES viável em 4 KB e o SNES inviável por ter duas CPUs. Felipe "Juca" Sanches observou que 4 KB era a memória do Patinho Feio, e Jecel Assumpcao Jr explicou que as instruções indexadas permitiam endereçar 64 KB e que tinha a impressão de ter visto algo sobre uma expansão para 16 KB.
Com 19 agentes do Opus 5.5, as 29 mil linhas de C++ da namagiri foram portadas para Rust em 2 horas, com os 512 testes passando. Com intrinsics de AVX2, a versão em Rust ficou tão rápida quanto a de C++.
RicBit contou que havia criado 490 casos de teste para a namagiri, até chegar a 99,8% de cobertura, e então a refez do zero; hoje a suíte tem 512 testes. Em seguida pediu ao Opus 5.5 que portasse as 29 mil linhas de C++ para Rust, tarefa concluída em 2 horas com 19 agentes e os 512 testes passando. A versão Rust ficou mais lenta, porque o g++ gera AVX2 automaticamente; com intrinsics de AVX2 ficou igual ao C++. L. sugeriu a biblioteca rayon e comentou os níveis x86-64.
RicBit portou o Galaga para o V9990 e vem refazendo à mão, com ajuda de uma rede neural, os gráficos do Death Wish 3. Também fez a abertura do Ys III com parallax em velocidade total e planejou medir o V9990 no hardware real. Ao testar o Ys III no turbo R, encontrou um defeito nos slots.
RicBit portou o Galaga para o V9990 do MSX, com gráficos tirados do arcade, todos os ângulos das naves e uma versão jogável na web. Explicou o limite de 16 sprites por linha, que impede três naves sem multiplexação, e Felipe "Juca" Sanches sugeriu tiros fora de sincronia. RicBit discutiu sugestões de Pablo Vasques Bravo-Villalba: estrelas coloridas, que foram incluídas, e o som do WSG no SCC.
RicBit mostrou o andamento dos gráficos refeitos à mão do Death Wish 3 para o V9990. Como LLMs não pintam e modelos de difusão erram muito com pixel art, treinou uma rede neural para gerar os quadros seguintes; o resultado sai cerca de 60% certo e ele corrige o resto à mão. Explicou que o colete precisa ser preciso no pixel porque o jogo verifica os acertos pelo bitmap.
RicBit fez uma prova de conceito do Ys III no V9990 com scroll parallax, com link para a versão original, que roda a 2 fps, para comparação. Pedro de Medeiros apontou o recurso de janela do V9990 (registrador R#27), que RicBit notou funcionar em blocos de 64 pixels. RicBit refez a abertura com cinco camadas de parallax, otimizou-a até velocidade total e traduziu o jogo para japonês, inglês e português. Notou ainda problemas de timing no WebMSX.
RicBit planejou ligar um turbo R com V9990 à rede e deixar o Claude medir os atrasos experimentalmente, para depois corrigir o WebMSX, e filmar a tela a 120 fps para medir o tearing. Com o mesmo arranjo pretende corrigir um bug do seu TMNT que só aparece no hardware real; ele suspeita do tratamento da tabela de atributos de sprites.
Ao testar o Ys III no turbo R, RicBit descobriu que os slots não reconheciam cartuchos. Como cartuchos leves funcionam, suspeitou da fonte e considerou usar um expansor de slots com alimentação externa, o que exige levantar o esquema de um expansor Ademir sem documentação. Felipe "Juca" Sanches sugeriu publicar o esquema.
Índice escrito por agentes Claude que leram o log completo de cada período. Um segundo agente conferiu cada conversa contra as mensagens, e um terceiro conferiu os resumos do ano e dos temas contra as conversas. Pode conter imprecisões: cada item leva às mensagens originais. Para procurar palavras específicas, use a busca.