Ano 1 · Ano 2 · Ano 3 · Ano 4 · Ano 5 · Ano 6 · Ano 7 · Ano 8 · Ano 9
Tópicos › Quinto ano › Mines, o campo minado coletivo e multiplataforma
Boa parte das conversas do ano tratou do Mines. Uma enquete escolheu uma licença livre copyleft, e o jogo é um campo minado com a lógica separada de drivers por plataforma, desenvolvido por pull requests no repositório ArqueologiaDigital/Mines. Pedro de Medeiros, Felipe "Juca" Sanches, L., Anne Isabelle e outros escreveram o código comum e ports para MSX2, a placa do GunSmoke, ncurses, MS-DOS, OpenGL e PlayStation, além de um port para Vectrex ainda em andamento, e Pablo Vasques Bravo-Villalba desenhou tilesets próprios. As conversas também cobriram integração contínua, fuzzing, depuração e detalhes de hardware como a temporização do VDP do MSX.
Quinto ano: novembro de 2021 a outubro de 2022
Felipe propôs um jogo retrô coletivo. As enquetes escolheram uma licença copyleft, a plataforma ficou empatada, e decidiu-se por um campo minado multiplataforma com o MSX como primeiro alvo. Discutiram-se bibliotecas para o SDCC (ubox, Fusion-C), as versões do SDCC, um grupo separado para o projeto e se o segundo passo seria outro jogo ou terminar o Mines.
Felipe "Juca" Sanches propôs que os membros programassem juntos um pequeno jogo para uma plataforma retrô e abriu uma campanha de três dias para sugestões de plataforma, além de uma enquete sobre a licença. Foram propostos Game Boy, MSX (com o compilador livre SDCC), Commodore 64, Master System/Mega Drive, V9990/MSX Turbo R e outros. Também se discutiu o uso de C com assembly inline e a decisão de trabalhar com emuladores.
Discutiu-se se dá para reaproveitar código entre Master System e Mega Drive. Erin Pinheiro explicou que o Z80 do Mega Drive costuma servir ao som, mas que o console tem um modo Master System, usado pelo Power Base Converter, em que o Z80 assume o controle, e citou NES/SNES como par mais compatível. RicBit, que já programou para MSX, Master System e Mega Drive, disse que o Master System é basicamente um MSX, mas que no Mega Drive quase não se reaproveita código do Master System porque as RAMs ficam mapeadas em endereços diferentes.
Pedro de Medeiros indicou a ubox-msx-lib e Leonardo Roman indicou a Fusion-C, ambas para o SDCC. Felipe "Juca" Sanches de início rejeitou a ubox pela licença CC BY-NC-SA indicada no site, mas João Carlos viu que o código está sob MIT e Pedro de Medeiros confirmou que só a documentação usa CC. Pedro de Medeiros explicou que a Fusion-C atende o MSX2 e a ubox só o MSX1, e que nenhuma das duas funciona com o SDCC 4.2.0.
A enquete de licença escolheu uma licença livre copyleft, como GPLv3 ou posterior. Na de plataforma, MSX, C64, SNES e MS-DOS empataram, e o PC Engine recebeu apoio fora da enquete. Felipe "Juca" Sanches propôs começar com um campo minado, com a lógica separada de "drivers" por plataforma, e Pedro de Medeiros sugeriu um Lunar Lander como passo seguinte.
O MSX venceu o desempate, e Felipe "Juca" Sanches criou o repositório ArqueologiaDigital/Mines para um campo minado em várias plataformas, com a lógica separada do hardware e desenvolvimento por pull requests. Pedro de Medeiros explicou que a versão nova do SDCC mudou a convenção de chamada, passando até dois parâmetros em registradores, e que __sdcccall(0) mantém o comportamento antigo. Também se discutiu acesso direto ao VDP/PSG versus rotinas da BIOS e se indicaram livros de referência sobre o MSX.
Ismael Luceno, Flávio Amieiro e Pedro de Medeiros verificaram quais distribuições já empacotavam o SDCC 4.2: Arch, Void e Source Mage sim; Debian testing/sid (4.0), openSUSE Tumbleweed e Gentoo ainda não.
Flávio Amieiro perguntou se o volume de mensagens sobre o desenvolvimento do jogo incomodava quem está no grupo por outros motivos. Felipe abriu uma enquete sobre criar um grupo dedicado, e Flávio sugeriu fixá-la para que quem silenciou o grupo também a visse. Pablo disse ser indiferente: achava positivo um grupo específico, mas não imprescindível.
Felipe perguntou se um segundo jogo poderia aproveitar o codebase e rodar em todos os ports; L. sugeriu snake ou Pipe Dreams, e Felipe lembrou que o port do GunSmoke veio de um snake com o Pixotosco. Pedro defendeu concluir antes todas as funcionalidades do Mines, incluindo timer, música e efeitos sonoros, para evitar ports incompletos e excesso de macros, e Felipe concordou; L. planejou diálogos de início e fim de jogo.
O núcleo da lógica e a versão ncurses vieram primeiro. Também foram tratados a API de entrada input_read, a API de vídeo baseada em tiles, a organização do código de plataforma, as regras de bandeiras e interrogação, o fim de jogo, o timer, o contador de minas, a geração de números aleatórios e ideias de modo para dois jogadores.
O repositório, que de início estava privado, foi tornado público com licença GPLv2 ou posterior. Discutiram-se a estrutura de pastas por plataforma e o uso de Makefile. Felipe "Juca" Sanches escreveu o núcleo da lógica do jogo e a interface ncurses, Pedro de Medeiros o sistema de build e a leitura de teclado para MSX, e Flávio Amieiro a entrada em ncurses. Também se discutiram as dependências hex2bin e makebin e um README por plataforma. Em 31/05 o jogo já estava "jogável" em ncurses, ainda sem detecção de fim de jogo; em seguida vieram PRs para bandeiras e abertura automática de regiões vazias.
Pedro de Medeiros e Felipe "Juca" Sanches redefiniram a função wait_for_any_key como input_read: não bloqueante, sem buffer e sem combinações de teclas, com bits para indicar o dispositivo (teclado ou joysticks 1 a 4) e ações como abrir célula, abrir bloco e colocar bandeira. Pedro de Medeiros documentou a função em um PR e, em outro, passou a usá-la, deixando os ports ncurses e MSX2 compilando.
Felipe abriu uma série de PRs no Mines: ação open_block, correção dos limites de movimento, exibição de todas as bombas ao explodir uma, tecla QUIT, Makefile de nível superior para compilar todas as plataformas e restrição de bandeiras a células fechadas.
Felipe planejou tela de abertura e de game over para o arcade, mudança do enum MINE_INPUT_ para valores sequenciais e uso dos DIP switches para configurar a dificuldade. Erin sugeriu headers genéricos com implementações por plataforma, como no fbdoom, e Pedro listou máquinas que poderiam receber ports a partir de um port para MSX1 (Coleco, SG-1000, SVI-318/328 e outras).
Pedro propôs uma implementação padrão de draw_minefield para plataformas baseadas em tiles; Felipe sugeriu colocá-la no diretório Common com uma pequena API de tiles implementada por plataforma. Pedro também enviou o PR #36 trocando um switch-case por um array de cores no GunSmoke.
Felipe notou que os números aleatórios não variavam porque a semente era sempre a mesma, no MSX2 (xorshift com semente 1) e no GunSmoke (semeado pelo relógio logo no boot). Pedro passou a usar o relógio de tempo real do MSX2 (PR #44); RicBit indicou a rotina RAND do seu Tetrinet, com polinômio maximal de 16 bits, e recomendou usar Seed = value | 1.
Felipe adicionou screenshots aos READMEs dos ports. Pedro apontou a necessidade de atualizar uma única célula da tela, e Felipe enviou o PR #49 com essa função para melhorar o desempenho em sistemas de vídeo lentos.
RicBit sugeriu um modo de dois jogadores, com jogadas alternadas e pontos por casas abertas. Felipe imaginou um campo grande jogado simultaneamente, com territórios de influência, bombardeios no campo do adversário e punições mais leves para erros.
Felipe abriu o PR #61 com o sistema genérico de vídeo baseado em tiles para revisão. Pedro implementou sprites modo 2 no MSX2, com o cursor como sprite (PR #62), corrigiu o Makefile para gerar e apagar mines.h (PR #63) e adaptou o código gerado para o SDCC 4.2.0 (PR #65).
No PR #87, Pedro moveu código exclusivo do OpenGL para a plataforma, e Felipe questionou a repetição de código. Felipe sugeriu uma struct de ponteiros de função como nos drivers do kernel Linux; L. argumentou que isso tornaria as chamadas indiretas sem benefício, pois há apenas uma implementação por programa.
L. propôs eliminar a dependência dos valores numéricos dos tiles para trocar o switch por uma tabela de offsets. Pedro explicou que o conversor XPM para SC5 ainda usa a ordem dos tiles, e Felipe registrou a issue #97 depois que uma mudança quebrou o MSX2.
Pedro abriu a issue #102 sobre suporte a mouse; L. lembrou que no PC basta ativar o driver pela int 33h. Pablo defendeu que cada plataforma tenha o cursor adequado às suas capacidades, e Felipe disse achar interessante que os ports tenham visuais diferentes.
Pedro abriu issues para uma função de timer e um contador de bombas e bandeiras; RicBit destacou que o contador de minas restantes é necessário para resolver certas situações de final de jogo.
Pedro enviou o PR #114 com o estado de fim de jogo no MSX2; Felipe pediu para renomear check_endgame, que retorna um novo estado e não um booleano. A vitória era indicada apenas pela ausência de explosão e do cursor, por falta de tiles para mensagem. Pedro depois enviou o PR #116 para o caso de célula com bandeira inválida.
L. mostrou diálogos no MS-DOS com a paleta escurecida. Pedro fez idle_update() controlar o fps com wait_tick() (PR #122) e explicou que no MSX o timer usa o hook HTIMI no retraço vertical, enquanto Felipe previu que o Vectrex precisará esperar o vsync e usar um campo menor; Pedro implementou depois timer e contador (PR #126).
Pedro passou a mostrar bandeiras colocadas incorretamente no fim do jogo (PR #130) e a manter as corretas no tabuleiro em vez de trocá-las por minas (PR #133). Felipe encontrou um bug: com uma bandeira errada, o open block pode detonar uma mina vizinha, enquanto o código assumia que a explosão ocorre sempre na posição do cursor. Pedro corrigiu a detonação múltipla no PR #134.
Pedro de Medeiros gera documentação HTML da API comum e do jogo Mines a partir do código, usando Python, pandoc e pygments.
O grupo discutiu o build (inclusive no Windows), e Pedro de Medeiros criou releases automáticos com GitHub Actions e uma interface de depuração sobre o debugdevice do openMSX. L. mostrou um modo de depuração no MS-DOS, sugeriu o gdbstub e propôs uma plataforma fuzzer com o qual relatou ter encontrado um bug.
A pedido de Pablo, Felipe compartilhou a ROM atual para facilitar ajustes nos tiles. Discutiu-se como compilar no Windows (make, SDCC, WSL, Python), e Pedro indicou o arquivo mines.png do repositório e sugeriu manter ferramentas compiladas numa pasta tools.
Pedro criou uma interface comum de depuração (PR #45) baseada no dispositivo virtual debugdevice do openMSX, ao qual o programa envia dados com instruções OUT. Num MSX real não há nada nessa porta e as operações são inertes.
Pedro trocou o srecord pelo MSXbin (PR #52). Felipe notou um erro de digitação no cabeçalho de licença (CC BY-AS em vez de CC BY-SA) e concluiu que, por ser uma ferramenta de build, não há conflito com a GPLv2+ do projeto. Após um merge que quebrou o build por falta do arquivo MINES.SC5, Felipe sugeriu adotar integração contínua.
Depois que Felipe mencionou um bug no open block na borda do campo, L. propôs uma plataforma fuzzer que lê teclas de um arquivo, compilada com o sanitizer de fuzzer e address do gcc, e logo relatou ter encontrado um bug. O primeiro patch não compilou e L. publicou uma segunda versão; depois explicou como o fuzzer muta a entrada conforme os branches executados até provocar um crash com backtrace.
Pedro separou build e install no port GunSmoke (PR #70) e criou um workflow do GitHub Actions que gera releases automáticos da ROM MSX2 (PR #71); o GunSmoke ficou de fora por exigir ROMs proprietárias para o patch, e Felipe disse que pretende gerar todas as ROMs sem depender delas. Felipe explicou o mapeamento de inputs no menu do MAME (TAB).
L. mostrou um modo de depuração no port MS-DOS e sugeriu o gdbstub, que implementa o protocolo do gdbserver e funciona via serial, para depurar qualquer port. Pedro observou que o código usa pragmas do GNU assembler não suportados pelo SDCC.
Felipe informou que o tkchia preparou pacotes do ia16-gcc para o Ubuntu Kinetic e sugeriu instalar pacotes via apt nas VMs do GitHub Actions em vez de usar Docker; Pedro lembrou que os pacotes que gerou não incluíam todos os headers, como conio.h, e L. observou que esse header não é mais usado.
Pedro de Medeiros levou o port de MSX2 de SCREEN 5 e comandos do VDP V9938 até um jogo com cursor por sprite, mouse, joystick e troca de tilesets. As discussões passaram pela temporização do VDP explicada por RicBit, por problemas de otimização do SDCC e pela falta de leitura de mouse na C-BIOS.
Pedro de Medeiros documentou a função random_number() e implementou a leitura de input no MSX2 (PRs #19 e #20). Felipe propôs reaproveitar a infraestrutura do seu antigo jogo Pixo para a placa JAMMA do GunSmoke, e Pedro explicou as diferenças entre SCREEN 4 (tile-based, com attribute clash) e SCREEN 5 (bitmap com blitter do V9938) no MSX2.
Pedro de Medeiros relatou ter aberto um chamado sobre bug no makebin do SDCC e enviou o PR #29 implementando random_number() para MSX, após discutir o intervalo retornado pela função.
Pedro propôs usar o srecord para gerar arrays C a partir da imagem em SCREEN 5 (4 bpp) para o MSX2. Felipe explicou que no GunSmoke o PNG vira XPM, embutido no programa patch_CGROM, que aplica um patch binário numa ROM original do jogo; L. comentou o tamanho de uma tela SCREEN 5 sem compressão (cerca de 32 KB).
Pedro enviou o PR #32 com o bitmap em ROM para o MSX2, convertido com o conversor online do Jannone, e buscou formas de automatizar a conversão. L. sugeriu um carregador de BMP de 16 cores com ImageMagick, e Pedro lembrou de seu script de GIMP que exporta para GRAPHICS 4 (SCREEN 5).
Pedro implementou as funções básicas de vídeo do port MSX2 em SCREEN 5 com o comando LMMM do VDP (PR #34). A discussão sobre usar OTIR/OUTI levou RicBit a explicar que o VDP lê a VRAM durante o traço e enfileira as escritas, de modo que escritas rápidas demais durante o traço se perdem, enquanto no retraço é possível escrever sem risco, e a descrever o comportamento do MSX turbo R, do V9938/V9958 e do Master System.
Pedro enviou o PR #38, com o port MSX2 lendo o teclado e jogável, embora lento por redesenhar a tela inteira. Felipe apontou os inputs que faltavam (OPEN_BLOCK e QUIT) e propôs refatorar a parte comum entre MSX2 e GunSmoke, o que facilitaria um port para MSX1 em SCREEN 1.
Foi definido o ciclo bandeira, interrogação e célula vazia no botão de bandeira, implementado por Felipe no PR #39. Pedro associou a tecla N ao OPEN_BLOCK no MSX (PR #40), e Pablo comentou as teclas usadas por Konami (N e M) e Compile (Shift).
Pedro observou que o SDCC 4.1.0 com --opt-code-speed deixava de atualizar o bit de célula aberta, o que não ocorria com --opt-code-size. Também renomeou os arquivos .z80 para .asm (exceto o crt0) no PR #51.
Felipe cadastrou issues no repositório. Pedro constatou que a C-BIOS até a versão 0.29 não implementa leitura de mouse (GTPAD), e RicBit observou que seria simples acrescentar isso à C-BIOS.
Pedro de Medeiros abre PRs que atualizam o contador de tiles, a interface de timer e o código da plataforma MSX2 no Mines.
Pedro de Medeiros adiciona suporte a mouse ao port MSX2 do Mines, com limpeza e autodetecção em PRs seguintes, e descobre que o clique do meio no openMSX cola a área de transferência na matriz de teclado. Ele documenta a função set_minefield_cell para que L. implemente mouse no port MS-DOS via int 33h.
Pedro de Medeiros integra o uso do comando HMMM do VDP e um novo tileset 16x16 feito por mrparn. O tileset antigo havia sido removido e, a pedido de Felipe, voltou com um mecanismo de troca de tilesets (PR #147).
Pedro de Medeiros conclui o suporte a joystick, corrige a convenção de chamada __sdcccall(0) e adiciona as funções platform_begin/end_draw e melhorias de depuração. Discute-se testar em MSX real ou em FPGA (SM-X, Zemmix, Multicore 2+), e Felipe se oferece para testar no hardware.
Felipe portou o Mines para o hardware de arcade do GunSmoke a partir da infraestrutura do jogo Pixo; no dia do merge o jogo já funcionava, ainda com cores incorretas. Ele estudou as camadas de vídeo da placa no driver do MAME, corrigiu a inicialização de variáveis globais no crt0 do SDCC após explicação de RicBit e discutiu tiles de fundo e a unificação da numeração de tiles com o MSX2.
Felipe abriu o PR #28 com o port do Mines para o hardware de arcade do GunSmoke, com tiles desenhados no GIMP e convertidos pelo Makefile para o formato de vídeo da placa, herdando o setup do jogo Pixo. Pablo perguntou sobre as especificações de vídeo da placa; ao fim do dia Felipe fez o merge e o jogo já funcionava, ainda com cores incorretas.
Lendo o driver do GunSmoke no MAME, Felipe aprendeu a programar os sprites, mas verificou que eles são sempre desenhados abaixo da camada de foreground tiles; os background tiles ficam em ROM e servem apenas para fundos estáticos. Abriu o PR #31 com duas formas de destacar a célula atual.
Após o PR #36, os números passaram a aparecer todos com a mesma cor no GunSmoke. RicBit explicou o teste do código _GSINIT (o LDIR com BC=0), e Felipe corrigiu o problema no PR #37 declarando as áreas INITIALIZED e INITIALIZER, cujos símbolos s__/l__ indicam início e tamanho e permitem copiar os valores iniciais da ROM para a RAM.
Pedro perguntou se é difícil alterar os tiles de fundo do GunSmoke. Felipe disse que começou a escrever código para isso anos atrás, talvez sem terminar, provavelmente no arquivo tools/patchBGROM.py, e que, se lembrava bem, os dados não são comprimidos, apenas embaralhados; pediu uma arte para voltar a testar o gerador de ROMs de background numa tela de abertura.
Pedro e Pablo propuseram células desenhadas com metatiles de 16x16; Pablo calculou que caberiam em 128 tiles e seriam viáveis em Master System e MSX1. Felipe e Pedro compararam como os IDs de tiles são definidos no GunSmoke (simbólicos, extraídos por coordenadas no patchCGROM.c) e no MSX2 (ordem da imagem SC5 em char_codes.h), visando unificá-los.
O port para MS-DOS em VGA modo 13h, compilado com ia16-gcc, foi acelerado e reduzido por L. de cerca de 32 KB para 4,6 KB, e L. conseguiu tocar áudio PWM no PC speaker. O grupo discutiu ainda a integração do som, música, um port PC booter e um port para Windows 3.11 com gcc-ia16 e OpenWatcom.
Felipe compilou o ia16-gcc para fazer um port para MS-DOS e notou que ele usa um assembler sob a licença OpenWatcom; L. lembrou a opção -m16 do GCC. O port em VGA modo 13h (PR #75) rodou no 386 de Felipe, ainda lento por plotar pixels via BIOS. Felipe tentou compilá-lo no GitHub Actions (PR #76) e abriu issue no build-ia16 sobre o PPA para Ubuntu.
Um patch de L. com escrita direta na memória VGA acelerou o port MS-DOS (aplicado por Felipe no PR #79). L. reduziu o executável com -Os, -flto e UPX, com uma compressão RLE de um nibble por pixel feita para o tileset (PR #88), com reduções no código comum (PR #93) e no próprio port MS-DOS (PR #110) e substituindo o crt0 do compilador (PR #112), chegando a 4,6 KB. Felipe testou no seu 386 e relatou que a versão otimizada ficou muito mais rápida que a anterior.
Felipe propôs um port que rode direto de um disquete de boot, sem MS-DOS, e listou as interrupções a reimplementar; L. explicou que só a int 0x21 é do DOS e descreveu o setor de boot. Felipe pensou em adaptar o jogo como EPROM de boot para seu clone de IBM PC 5150 em CGA, e Erin explicou que o CGA é bitmap de 2 bpp com interleave de 8 KB. Felipe também lembrou que Patinho Feio e a VM do Another World não têm compilador C.
L. e Felipe discutiram opções de música para o port de PC (AdLib, PC speaker) e referências sobre tocar MOD no PC speaker. RicBit ofereceu seu player de MOD em Java para ser portado para C.
L. começou um leitor de MOD e notou campos com quantidades muito diferentes de minas no port MS-DOS. Trocou random_number() por uma versão de 16 bits do algoritmo de Lemire e depois concluiu que o comportamento estava correto: o número de bombas é sorteado entre 10 e 30.
L. conseguiu tocar áudio PWM de 8 bits a 16 kHz no PC speaker, e Felipe confirmou o ruído de teste no seu 386. O PR #128 inicialmente só funcionava fora do modo gráfico; L. corrigiu a rotina de interrupção ao perceber que um pushf e o carregamento de BX estavam em ordem errada, e passou a precisar de efeitos sonoros.
Felipe pergunta como gerar executáveis Win16 com gcc-ia16 para portar o Mines para Windows 3.11. L. explica os formatos MZ, NE e PE, e Felipe propõe pôr as versões de DOS e de Windows num único binário. A licença não livre do OpenWatcom e a possibilidade de mudá-la são debatidas. Ismael Luceno sugere Win32s e relembra a história do Watcom e do DJGPP em jogos como Quake e Doom.
Felipe propõe integrar o patch de som de L. para o port MS-DOS usando arquivos WAV livres provisórios. L. explica as limitações do modelo de memória tiny, a opção de ler o áudio de arquivo com far pointers e os problemas de uma ISR em C (inclusive com LTO), e sugere escrever a ISR em assembly com ring buffer.
V Körbes chega ao grupo e compartilha seu repositório de estudos de programação para MS-DOS. L. indica o port MS-DOS do Mines, escrito em C com assembly inline, como referência de técnicas para binários pequenos.
Felipe fez uma versão 3D em OpenGL e começou o port para Vectrex, que ainda esbarrava no toolchain gcc6809. Anne Isabelle começou, com João Carlos, um port para PlayStation com o PSn00bSDK, que rodou num console real carregado por cabo serial, ainda com bugs; mais tarde o projeto estava parado e Felipe propôs retomá-lo. Também se cogitou um port para CoCo/CP400.
Felipe abriu o PR #78 com uma versão 3D do Mines em OpenGL e foi corrigindo o modelo dos ladrilhos e o redesenho da cena; restavam as cores e a iluminação, que deixava a cena em tons de cinza. Ao fim do dia fez o merge do PR.
Felipe abriu o PR #111, um rascunho quebrado do port para Vectrex, depois de dificuldades com o compilador CMOC. L. indicou versões do gcc6809; Felipe compilou a versão do GitLab substituindo caracteres 0xA0 que quebravam a documentação texinfo, mas o link falhava por falta de libc.a.
Felipe passou a usar o gcc6809 no port Vectrex e viu que faltava compilar a newlib-6809. Para chamar a rotina de números aleatórios da BIOS, L. explicou a sintaxe de assembly inline do GCC; a forma sugerida por ela gerou erro de constraint, e Felipe voltou à sua implementação original, verificando o resultado no debugger do MAME. Descobriu que o linker colocava variáveis em ROM, e não na RAM em C800-CBFF, e concluiu que precisa de um linker script.
Anne Isabelle começou um port para PlayStation com o PSn00bSDK e abriu o PR #127 como rascunho, trabalhando com João Carlos. O grupo discutiu fluxo de trabalho com draft PRs e branches de vida curta; em 26/06 o port já desenhava a grade. Felipe pediu que a dependência do CMake fosse a versão 3.18.4 do Debian, e Anne explicou que a biblioteca exige a 3.20, segundo a documentação, e que testaria a versão anterior.
Robson França chegou ao grupo por um link postado no grupo de TRS Color; a pedido de Felipe, o link do grupo Clube Color Brasil foi compartilhado (postado por Felipe). Pedro perguntou se já existe campo minado para TRS-Color, e Felipe observou que portar o Mines para o CP400 usaria um toolchain parecido com o do Vectrex, pois ambos usam o MC6809.
Anne Isabelle montou um cabo serial USB-TTL (CP2102) para carregar programas no PlayStation real, usando o UniROM no console e o nops no PC. A primeira falha de imagem vinha do próprio código (um hello world rodou), e uma inversão de cores foi causada pelo RetroTINK. Depois disso o port do Mines rodou no console, com o mesmo bug de background visto no emulador. Felipe fez o merge do PR #127, com a base do port, e Anne abriu em seguida os PRs #135 e #139. Felipe também montou o ambiente com toolchain e emulador e reproduziu o flickering ainda pendente.
Anne Isabelle comentou que o projeto do Minesweeper para PlayStation estava parado e que só o grid havia tomado cerca de duas semanas. Felipe "Juca" Sanches propôs retomá-lo e ajudar, e Anne sugeriu marcar um domingo. A conversa passou depois para o preço de consoles antigos e monitores CRT em Londres, onde Felipe citou um CRT VGA a 40 libras. L. disse que os PVM da Sony também são caros onde mora. Erin Pinheiro 🐿 contou que terá de vender seu 14L2U quando sair do Brasil: um dos últimos da linha de tubo, vindo de uso médico, com poucas horas de uso.
O grupo discutiu os gráficos do jogo, e Pablo Vasques Bravo-Villalba desenhou um tileset com grama e pedras e protótipos de metatiles de 16x16 em estilo clássico e em estilo abstrato para o TMS9918. Também se comentou o Mine Finder, campo minado para MSX1 inscrito na MSXdev22.
Pedro pediu voluntários para redesenhar os gráficos do MSX2, e a conversa passou pelo visual do campo minado do Windows 3.1, por texturas de grama e buracos sugeridas por L. e por ideias de versões isométrica, vetorial (Vectrex) e 3D. L. indicou um campo minado feito para o Master System numa competição da SMS Power.
Pablo desenhou um tileset de 13 cores com grama e pedras, e Pedro o aplicou no MSX2 (PR #41). Felipe apontou problemas de legibilidade no destaque de algumas células e questionou o desenho das minas; Pablo explicou que eram minas terrestres em perspectiva e sugeriu indicar a seleção pelos tiles vizinhos ou por um sprite.
Mensagem encaminhada anunciou o Mine Finder, de Paolo Pugno, versão de campo minado para MSX1 inscrita na MSXdev22. Mais tarde Felipe observou que ele usa todos os tiles para células, sem grade, o que permite um campo maior.
Pablo apresentou protótipos animados com metatiles de 16x16: um estilo clássico inspirado no Windows 3.1, com cursor de mouse, para sistemas com pelo menos 15 cores, e um estilo abstrato que respeita as restrições do TMS9918 do MSX1, com cursor crosshair animado feito de sprites. O grupo discutiu temas, fases com tilesets diferentes e Felipe lembrou seu campo minado hexagonal em JavaScript.