Adaptação de jogos de fita para Beta 48 (parte 8)

Hoje eu fiz a adaptação de Rogue Trooper para o Beta 48 e, como venho elaborando uma série mostrando como se faz isto, aproveito para apresentar mais uma técnica. Deste vez abordarei como usar visualizador de memória do emulador Fuse. Apesar de mostrar o procedimento neste emulador, outros dotados de um debugger poderão ser usados.

Para ter acesso ao BASIC, pode ser usado o comando Z BLOAD do STK. A listagem é protegida por códigos de controle, portanto bastaria a princípio usar o comando L LIST no STK... mas não funciona! Eu não sei ao certo o motivo, mas talvez seja porque muitas linhas estão com o mesmo número (0). No BASIC, só dá para ver uma linha:
ou a linha:

A solução que imaginei foi renumerar a primeira linha (com POKE 23756,1) para depois deletá-la. Deu certo, apareceu a listagem do restante do programa BASIC:

A primeira linha incrementa a variável ah, seu valor é 1. Isto significa que quando se está executando a segunda linha, ah terá valor 1 e será executada rotina em 23768. Aparentemente ah é inicializada com 0 na primeira vez que o programa foi rodado, que executa a última linha que aparenta ser uma rotina de gravação.

Para entender o processo de carregamento, deve-se fazer o disassembly da rotina em 23768:

Inicialmente o endereço da pilha do Z80 é colocado em 0, a tela é apagada, uma rotina em código de máquina é copiada para 65024, onde é executada. Com breakpoint em 65024, o disassembly revela:

que é claramente uma rotina de carregamento da fita de um bloco de 48512 bytes a partir do endereço 16384 (primeiro byte da RAM). Seguindo o disassembly, chega-se a:

Fica claro que esta rotina carrega quase que toda a RAM (16384 a 64895), incluindo uma tela. A princípio poder-se-ia pensar em salvar toda esta parte em disco, mas não iria funcionar porque os 112 bytes de variáveis do sistema TR-DOS se sobreporiam. Antes de tomar qualquer medida, seria interessante observar o conteúdo da RAM com a opção Machine > Memory Browser.... O interessante que a região ao redor de #5D00 a #5E00, próximo às variáveis de sistema e do programa BASIC, lembra a listagem do carregador:


Isto é um bom sinal, pois mostra que o programa mantém a RAM de BASIC razoavelmente intacta. Depois desta área, há um longo trecho vazio (isto é, preenchido somente com valores 0) até chegar a #7000 (28672). Este endereço é um valor que aparece tanto na listagem BASIC como no disassembly, o que dá uma pista de que o código de máquina de jogo se inicia ai.

A conclusão da análise do conteúdo da memória é que há um sistema BASIC relativamente intacto, o jogo propriamente dito entre 28672 a 65023 (36352 bytes) e a rotina de carregamento headerless a partir de 65024.

A estratégia de adaptação do jogo fica definida. Inicialmente define-se um breakpoint em 28672 e carrega-se normalmente o jogo. Grava-se no disco do PC a tela e o conteúdo de RAM entre 28672-65023. Depois de fazer reset no emulador e inserir um disco virtual TR-DOS, grava-se a tela e o bloco de bytes. Por fim um carregador BASIC é criado e salvo no disco:

Tweet