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:

0 REM

ou a linha:

256 REM Hello

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:

0 LET ah=ah+1 

0 IF ah=2 THEN RANDOMIZE USR 23768 

0 SAVE "Rogue" LINE 0: CLEAR 65535: LOAD ""CODE 28672: LOAD ""CODE 16384: RAND USR 23950: RAND USR 65024

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:

23768   LD SP,0
23771   LD HL,16384
23774   LD DE,16385
23777   LD BC,6911
23780   LDIR
23782   LD HL,23796
23785   LD DE,65024
23788   LD BC,148
23791   LDIR
23793   JP 65024


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:

65024   LD IX,16384     ; Endereço inicial.
        LD DE,48512     ; Carregar 48512 bytes.
65031   DI              ; Rotina de carregamento.
        LD A,8
        OUT (254),A
        IN A,(254)
        LD C,0
65040   CALL 65142
        JR NC,65040
65045   LD HL,1045

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:


65135   JP 28672        ; Após carregamento, iniciar jogo em 
                        ;28672.

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:

10 PAPER 5: INK 5: BORDER 5: POKE 23624,45: CLEAR 28000
20 RAND USR 15363: REM : LOAD "ROGUETR$"CODE
30 RAND USR 15363: REM : LOAD "ROGUETRc"CODE
40 RAND USR 28672

O jogo adaptado pode ser baixado do Goggle Drive ou do 4 Shared.