Ano 1 · Ano 2 · Ano 3 · Ano 4 · Ano 5 · Ano 6 · Ano 7 · Ano 8 · Ano 9
Tópicos › Sétimo ano › MSX, Z80 e ferramentas de engenharia reversa
RicBit aplicou IA ao MSX: um depurador com ChatGPT e openMSX, um modelo que gera imagens em screen 2 e um emulador com legendas traduzidas automaticamente. Houve também discussões técnicas sobre Z80, YM2413, recompilação estática e compressão. Outras ferramentas debatidas foram o Ghidra, o Spectrum Analyser e extensões do depurador do openMSX.
Sétimo ano: novembro de 2023 a outubro de 2024
RicBit criou um GPT customizado que controla o openMSX e o usou para desassemblar e comentar o Antarctic Adventure. A conversa tratou dos erros do modelo e das limitações de contexto.
RicBit criou um GPT customizado, o "MSX Debugger", que controla o openMSX por meio de uma interface Python e do modo --control stdio (cadeia ChatGPT → Flask → XML → Tcl → openMSX). O modelo recebia trechos resumidos do MSX Red Book e foi usado para desassemblar e comentar o Antarctic Adventure. A conversa tratou da janela de contexto pequena, da memória externa via webhook, dos erros do modelo (tratar LDIR como cópia quando era preenchimento, errar a aritmética de endereços) e da decisão de passar a aritmética para o servidor. RicBit indicou a documentação de GPT Actions para quem quisesse montar algo parecido.
O emulador reconhece o texto japonês por OCR e mostra legendas traduzidas. Depois, RicBit contou que o projeto estava parado: a tradução custa cerca de US$ 3 por dia de uso e precisaria de um cache, cuja chave é difícil de definir quando o LLM mantém contexto entre telas.
RicBit apresentou um emulador de MSX que reconhece por OCR o texto japonês na tela e mostra legendas em português geradas pela API do Google Translate. O grupo discutiu a falta de contexto entre telas e a ideia de execução especulativa: emular uns 300 quadros adiante, mantendo vários save-states. RicBit também testou um LLM, que melhorou muito a tradução mas tem latência alta, e calculou o custo das chamadas de API, que considerou inviável para uso por outras pessoas sem otimização. Discutiu-se ainda como deduzir o encoding do texto na memória a partir do OCR. Na VRAM de Undeadline, RicBit observou uma animação feita por color cycle.
RicBit contou que o tradutor automático do emulador estava parado. A tradução custa cerca de US$ 3 por dia de uso e precisaria de cache, mas o uso de LLM para manter contexto entre telas dificulta definir a chave desse cache.
RicBit treinou um modelo que gera imagens compatíveis com o screen 2 do MSX1 e mostrou model sheets em pixel art geradas com GPT-4.
Shelton Ribeiro divulgou o pedido de um programador que tem uma engine própria em C++ para um shoot 'em up de Dreamcast em 320x240 e procura um artista 2D para fazer 3 ou 4 fases. RicBit sugeriu usar IA e mostrou model sheets em pixel art geradas com GPT-4, incluindo o prompt usado. João Carlos notou que a IA se perdeu na numeração das etapas.
RicBit treinou um modelo de IA que gera imagens com a paleta do MSX1 e encaixa as cores nos blocos de 8 pixels do screen 2. As saídas, convertidas com o mifui sem error diffusion, ficaram quase iguais às originais, e ele as comparou também em screen 4 e screen 5. L. e RicBit discutiram o uso de um borrado de CRT ou de uma GAN para melhorar o resultado.
O Spectrum Analyser foi comparado ao ExecTrace de Felipe e aos recursos do openMSX. Pedro de Medeiros abriu PRs no openMSX para breakpoints com slot/subslot e para desmontar strings binárias.
L. compartilhou o Spectrum Analyser, que reúne emulador, depurador e disassembler interativo para jogos de ZX Spectrum. Felipe "Juca" Sanches viu nele funções que planeja para o seu projeto ExecTrace, incluindo a integração com o depurador do MAME. RicBit lembrou que o openMSX já oferece isso há cerca de 15 anos e contou que instrumentou o emulador com um script em Tcl para medir o tempo gasto em cada instrução de MSX BASIC (cerca de 1 a 2 ms por instrução).
Pedro de Medeiros abriu um PR no openMSX para criar breakpoints com informação de slot/subslot no gerenciador de símbolos e pediu sugestões de recursos para o depurador.
Pedro de Medeiros abriu um PR no openMSX com uma extensão para desmontar qualquer string binária em Tcl. Ela serve a um script que gera assembly dinamicamente, como o Spectrum Analyser.
RicBit abriu uma ROM de MSX no Ghidra, e Felipe procurou ferramentas de IA para interpretar disassembly. Pedro de Medeiros indicou um módulo do Ghidra para TLCS-900/H.
RicBit contou que aprendeu a usar o Ghidra e que ele abriu uma ROM de MSX. L. comentou que há plugins para muitas CPUs e que o Ghidra é mais fácil de usar que o radare, e Anne Isabelle concordou.
Felipe "Juca" Sanches procurou ferramentas de IA para ajudar a interpretar disassembly. Ele encontrou um assistente de engenharia reversa para o Ghidra, ainda não avaliado, e um artigo no arXiv sobre o tema. RicBit aprovou a ideia.
Pedro de Medeiros compartilhou a fonte OpenType Z80 Sans, que faz o disassembly de instruções Z80. Também indicou a Felipe "Juca" Sanches um módulo de processador TLCS-900/H para o Ghidra, e Felipe disse que iria testá-lo.
Os assuntos foram o fim da produção do Z80 pela Zilog, uma proposta de virtualização no MSX via HALT/NMI, o parser JSON de 768 bytes de RicBit, um projeto japonês para MSX0 que usa a biblioteca JSON de RicBit e os mnemônicos de rotação do Z80 e do TLCS-900.
L. avisou do fim da produção do Z80 pela Zilog, e Pablo comparou o Z80 com o 6502. Luciano Ramalho lembrou uma demonstração de Etienne Delacroix na Poli: um Z80 sem RAM incrementava o contador de programa e a contagem aparecia em LEDs. L. compartilhou o z80-open-silicon, clone open-source do Z80 em silício.
Os pontos de partida foram um emulador de 6502 que roda em 6502 e um artigo sobre um emulador de Z80 com precisão de ciclo. RicBit propôs ligar o sinal HALT a um pino não conectado do slot do MSX para disparar NMI e trocar de contexto. Ele também listou três comportamentos que considera errados em todos os emuladores: uma sequência de EIs com interrupção no meio, o mux de entrada do FM-PAC e o latch da saída PCM do turboR.
RicBit mostrou como sobrepôs tabelas de constantes no seu parser JSON para Z80, que tem 768 bytes e, segundo ele, é 100% compatível com o padrão. L. descreveu seu parser JSON em C, que preenche structs diretamente, e a conversa passou por geradores de código a partir de DSLs, como o protobuf.
RicBit compartilhou um projeto japonês de relógio e termômetro para o MSX0 que usa sua biblioteca de leitura de JSON.
Pedro de Medeiros criticou o fato de, no TLCS-900, RLC significar rotação sem carry, padrão que, como Pablo lembrou, vem do Z80. Pablo explicou a diferença entre a rotação de 8 bits (RLC) e a de 9 bits com carry (RL).
Os assuntos foram o MSX em FPGA do LSI-USP, a decapsulação de chips do MSX, a teoria de RicBit sobre os atrasos de escrita do YM2413, um MSX2 em protoboard e teclados mecânicos.
A partir de um artigo sobre FPGAs e hardware retrô, L. lembrou o projeto de MSX em FPGA do LSI da USP, do qual RicBit e Felipe "Juca" Sanches participaram. RicBit contou que, pelo que se lembra, o projeto começou por volta de 2001 e que o primeiro MSX completo saiu em 2003, ainda com um Z80 discreto, porque o processador não cabia na FPGA da época.
Pedro de Medeiros e Pablo Vasques Bravo-Villalba compartilharam tópicos do MSX Resource Center sobre a decapsulação dos chips V9990, SCC e V9958.
L. compartilhou um teclado mecânico para C64 e sugeriu fazer um para o Expert. RicBit mostrou o teclado que usa, e Pedro de Medeiros observou que teclas como F12 conflitam com atalhos do openMSX.
RicBit expôs a teoria de que os atrasos exigidos após escrever num registrador do YM2413 vêm de um contador interno que percorre os registradores. Segundo ele, a teoria bate com o datasheet e permitiria escrever vários registradores numa sequência calculada. A conversa passou ao interleave de setores, que acelera a leitura de disquetes pelo DOS/BASIC do MSX, aos erros de RAM causados por raios cósmicos e ao armazenamento de disquetes perto de HDs.
Felipe repassou o projeto H2Z80, um computador Z80 montado com fiação manual. L. mostrou fotos de seu MSX2 em protoboard, nunca concluído, incluindo uma protoboard feita especificamente para o VDP.
L. testou à mão a tradução de assembly para C, e RicBit lembrou uma versão do BrMSX com dynarec. RicBit também descreveu um compressor para textos de RPG de 8 bits e se ofereceu para otimizar, se preciso, o BrMSX no Pocket 386 de L.
A partir da notícia sobre a recompilação de jogos de N64 para PC, L. fez à mão um teste de tradução de assembly para C, com uma função por rótulo e tail calls ([[musttail]]) entre elas. Tevo citou o port do Open Genera para Linux, que compilava para C o assembly de DEC Alpha do emulador do Ivory. RicBit lembrou de uma versão do BrMSX com dynarec, que funcionava bem com jogos japoneses rodando em ROM e mal com jogos espanhóis automodificáveis rodando em RAM.
A partir de um artigo sobre o uso de BSP no Doom, RicBit mostrou e criticou sua própria implementação de 1995. Depois descreveu um compressor com símbolos de tamanho variável, baseado no método MIS, útil para descomprimir trechos aleatórios de texto em jogos de RPG de 8 bits. Segundo ele, a ideia era fazer o Shalom caber em 256 KB, mas o resultado ficou com 512 KB.
L. comprou o Pocket 386, um laptop atual com 386SX de 40 MHz e 8 MB de RAM, e o recebeu cerca de dez dias depois. L. pensou em rodar nele o BrMSX para DOS; RicBit se ofereceu para otimizá-lo, se preciso, e sugeriu testar com Nemesis.