Telas do speccy no MSX – parte 3

tbzscmcb-3_abertura

Depois do hiato da semana passada segue continuação da série sobre a construção de um visualizador de telas do ZX Spectrum para MSX-DOS. Só para recordar a primeira parte tratou da organização da memória de vídeo do speccy, das diferenças dela com a do MSX e de como compensar as tonalidade das cores. Na segunda parte foi sobre como reorganizar os dados do arquivo SCR para apresentá-los na VRAM do MSX e, claro, como fazer a carga dele usando diretamente as rotinas da BDOS.

Há também uma parte complementar com um pequeno programa em Python que converte telas do ZX para dumps da VRAM em arquivos binários do MSX.

Nesta parte, conforme foi prometido, é a recuperação e tratamento dos argumentos passados pela linha de comando do MSX-DOS e como o assunto é meio chato tentarei ser breve — eu juro 😀

A linha de comando

O MSX-DOS armazena diversas informações de ambiente nos primeiros 256 bytes da memória, a página zero¹, lá estão algumas variáveis do sistema operacional, os pontos de chamadas para diversas funções e, claro, o o resto da linha de comando (tudo aquilo depois do nome do programa) inserida pelo usuário a partir do prompt no COMMAND.COM.

O número de caracteres que foram digitados é armazenado no endereço 0x0080 enquanto que o texto em si está entre 0x0081 e 0x00FF (só lembrando que os programas começam em 0x0100). Tecnicamente isto significa que a linha de comando tem no máximo 127 caracteres mas na prática ela é composta de “somente” 126 caracteres já que um caractere de espaço é automaticamente inserido entre o nome do programa e o resto da linha.

(¹) Que é o mesmo comportamento do CP/M no qual ele foi baseado porém é importante ressaltar que o MSX-DOS não é um clone CP/M! Algumas funcionalidades, mas não todas, estão implementadas da mesma forma e no mesmo lugar — hoje seria como dizer que “usa a mesma API” — e isto serve para torná-lo compatível mas não necessariamente igual.

Recuperando a linha de comando

Infelizmente não há uma função dentro do MSX-DOS que interprete e retorne de modo automático os argumentos passados na linha de comando, como acontece como acontece com argc e **argv em C.

Assim a solução é trabalhar com as informações que o sistema operacional disponibiliza para fazer algumas experiências.

Monte com:

$ pasmo -d -v viewArgs.asm viewargs.com

O que faz? Simples, verifica se foi inserido algo após o nome do programa lendo o valor do endereço 0x0080 e sendo ele maior que zero imprime o conteúdo.

Apesar de feito para rodar no MSX-DOS este programa foi intencionalmente escrito para ser compatível com implementações de CP/M em computadores Z80² por um simples motivo:

tbzscmcb-3_cpm

No CP/M — via emulador rodando dentro no DOSEMU, ufa! — há uma diferença interessante em que a linha é totalmente convertida para caixa alta. Aliás, eu não dissera que MSX-DOS ≠ CP/M? 🙂

(²) Só lembrando que Z80 e 8080 compartilham um conjunto comum de instruções mas não de mnemônicos.

Interpretando argumentos

Então, a partir da estrutura do primeiro programa, é possível criar um interpretador de argumentos passados pela linha de comando mas antes de fazê-lo é necessário considerar algumas premissas importantes:

  1. Os argumentos são tudo aquilo que segue o nome do comando até o limite dos 127 126 caracteres;
  2. O primeiro argumento será sempre um nome/máscara de arquivo;
    • Um nome/máscara de arquivo terá no máximo 12 caracteres³ — até 8 caracteres para o nome, até 3 para extensão e um “.” a separá-los;
  3. Os demais argumentos serão parâmetros indicados pelo caractere de barra (“/”);
    • Os parâmetros usarão letras — /a, /b, …, /z — ou números — /0, /1, …, /9 — e
    • Terão o tamanho máximo de um caractere.
  4. Os parâmetros serão sensíveis à caixa das letras, ou seja, serão case sensitive — desculpe CP/M.

Assim:

Para montar use:

$ pasmo -d -v testArgs.asm testargs.com

Este programa é só um exemplo, ele identifica um nome de arquivo e a presença dos parâmetros “/H” ou “/h” para exibir a mensagem de ajuda. Estes parâmetros são excludentes (é um ou o outro — no caso é o primeiro a ser utilizado) mas esta é uma característica do programa e não desta rotina.

(³) Neste momento estou desconsiderando a compatibilidade com a versão 2.x do MSX-DOS que tem suporte a subdiretórios.

Finalizando esta parte

Deixei disponível uma imagem de disco com estes dois programas já montados para quem quiser se divertir um pouco. E agora com todas as rotinas prontas é possível juntar tudo para, finalmente, criar a ferramenta. Aliás eu acho que deveria ter escrito o visualizador em SDCC e não diretamente em Assembly, mas agora é tarde… 🙂

Até!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s