Sim, o prometido artigo saiu. Agradeçam ao vírus aí do lado por isso. A desculpa acabou, aqui está o texto que estou devendo há anos. Finalmente, a solução que eu desenvolvi está disponível, encerrei o artigo, revisei, fiz um pacote zip, subi pra um canto (não, eu não consigo me entender com o git e o github) e documentei o que faltava. Espero que vocês usem, comentem, e me ajudem a incrementar essa solução.

O início

No princípio era o Verbo… Não, texto errado. Eu, como MSXzeiro, sempre quis fazer algo que fosse útil para quem usa o micro. Não só jogos, como todo mundo, mas também utilitários que facilitassem nossa vida. Aliás, com o tempo eu descobri que eu gosto mais de programar utilitários e pequenos aplicativos do que jogos. Vai entender…

Eu vou poupar vocês das explicações a respeito dos motivos de usarmos ambientes de desenvolvimento cruzado, vantagens e desvantagens, essas coisas. E nem vou ficar explicando porque eu escrevo código em Pascal, e não em Assembly ou C ou BASIC ou qualquer outra coisa no MSX. Vamos direto ao ponto.

A principal limitação, minha e de todo mundo, é tempo. Então uma solução para mim seria programar no ambiente no qual eu estou mais acostumado, escrevendo código na linguagem que eu gosto, para o computador que eu mais tenho apreço. Logo, montar um esquema para escrever código Pascal dentro do Linux, e compilá-lo para usar no MSX.

Esbarrei em várias dificuldades, e tentei resolver da melhor maneira possível. Desde conversar com os desenvolvedores do FreePascal para adicionar suporte ao Z80 (acho que não me levaram a sério) até procurar compiladores como o Z80 Pascal, sem sucesso. Então, vamos fazer “da nossa maneira“.

O que eu fiz então foi usar um editor de código fonte no Linux, e quando eu mandar compilar o código, ele chama um emulador, executa o compilador dentro do emulador e o código é compilado em um micro emulado. Isso eu consegui e pode ser usado para outros compiladores, de outras linguagens (C, por exemplo). Claro que hoje em dia há soluções mais efetivas, como o Fusion-C, mas eu programo em Pascal mesmo.

E eu não sei como fazer tudo isso funcionar no Windows. Gente, entenda, eu não uso Windows, e nem tenho um Windows a mão para configurar. Mas eu acho que é algo razoavelmente simples, em tempos de Windows 10 para Criadores e bash substituindo o PowerShell… Mas acho que para Mac OS X deve ser ainda mais simples ainda, visto que é Unix também. Se alguém quiser ajudar com isso, seria ótimo. Agradeço toda a ajuda.

O compilador

Eu queria usar as comodidades do mundo moderno, como realce de sintaxe, edição de múltiplos arquivos, etc. Mas estou enferrujado no Pascal, não leciono numa turma de programação básica há muitos anos. A faculdade onde eu lecionei, migrou tudo para Java, mas faliu alguns anos depois (longa história). Nisso, eu me foquei mais em disciplinas de arquitetura, infraestrutura e redes. Então, Pascal ficou largado no passado e eu decidi retomá-lo. Está sendo um prazer e uma luta para relembrar tudo.

Para a solução que eu queria, teria que ser um compilador de linha de comando. Por mais que o Turbo Pascal 3.0 do CP/M (e que rodamos no MSX) seja excelente, ele é um compilador + link-editor + editor. Decidi deixar ele por último, para gerar o código final.

Peguei o TP33F, do Frits Hilderink para trabalhar. Ele tem umas coisas muito legais, como suporte a tipos longos de inteiros (que faz MUITA falta no TP3), e é um compilador de linha de comando. Mas tem também o bendito do GIOS já dentro dele (que é uma biblioteca gráfica pré-compilada) que aumenta o código final em 3 a 4 Kb (em termos de MSX, é muito). O pacote (disponível nesse link aqui) traz muitos códigos de exemplo, mas o mais chato é que a documentação está em… Holandês. Eu comecei a traduzir via Google Translate, mas não concluí a tarefa (alguém aí interessado em ajudar?).

Uma das coisas que eu vi que ele tem, é que ele traz um compilador cruzado para MS-DOS junto. Mas eu acabei usando o compilador de linha de comando para MSX mesmo. Explico aí embaixo.

O emulador

Gostaria de fazer uma ressalva antes de continuar. Eu tentei usar um emulador de MS-DOS (DOSBox) para usar o compilador cruzado do TP33F para MS-DOS. Sofri muito e desisti. Os problemas vinham desde o interpretador de comandos do DOSBox até variáveis de ambiente que precisavam estar setadas. Muito complicado.

Então, vamos de emulador. O OpenMSX é um emulador cujo foco é facilitar a vida de quem programa pra MSX. Sim, tem o Catapult, que é bom para quem joga. Mas eu queria mesmo era programar alguma coisa. Ainda estou tateando no OpenMSX, aprendendo a usar o debugger, essas coisas. Mas o básico eu consegui fazer.

Quanto à instalação do OpenMSX, eu não vou me deter nisso. Se você quiser saber mais, tem um post ótimo no blog do Ag0ny que ajuda muito nesse processo.

Códigos e gambiarras

Eu tenho muitas bibliotecas em Pascal para MSX. Muitas mesmo. Recuperei várias que eu usava nos anos 1990, e estão mal e porcamente documentadas. Separei em pastas, com o cuidado delas não ultrapassarem 720 Kb de tamanho.

Então, decidi fazer o seguinte: Eu teria uma pasta, chamada sandbox, onde estariam os arquivos a serem compilados. Esse script iria copiar os arquivos para dentro de uma imagem de HD que eu usaria, criaria um arquivo batch que seria executado pelo emulador.

Logo, o script faz o seguinte:

• Limpa o conteúdo da pasta sandbox;
• Copia o conteúdo da pasta onde está o programa a ser compilado para a sandbox;
• Cria um arquivo batch, chamado COMPILA.BAT, que irá compilar o programa.
• Executa o emulador para compilar o dito cujo.

Quando o emulador é encerrado, ele copia o conteúdo dessa pasta, sandbox, para a pasta original.

O ambiente

Como disse, queria trabalhar com um editor de código-fonte que me permitisse ter algumas das flexibilidades do mundo moderno. Realce de sintaxe é algo muito interessante, fora todas as outras facilidades.

Alguns de vocês poderão gritar nesse momento: Eclipse! E outros responderão: Netbeans! Alguns ainda gritarão: Atom! Haverão ainda aqueles que vociferarão: Vim! E aí, lutarão pela supremacia por toda a eternidade… E eu os ignorarei. Lembre o que eu disse lá em cima: Eu não sou programador de profissão. Programo no MSX porque adoro essa máquina. Logo, eu teria que antes aprender a usar essas IDEs e ambientes e editores… E aí foge do escopo do problema. É verdade que existem soluções muito azeitadas para programação, usando Eclipse, C e MSX. Mas eu não queria algo tão complexo.

Eu falei do Atom ali em cima? Pois é, ele é um editor de código multiplataforma. Muito bacana… Até eu tentar instalar na minha Linuxbox e o sistema pedir 563 Mb de instalação, só para escrever um código em Pasca.? Muita coisa. Pensei no gedit, editor de textos padrão do GNOME, e lembrei da solução do Rafael Jannone, com um plug-in para controle do OpenMSX. Cheguei a conversar com ele, mas o que eu queria era que o script controlasse o OpenMSX. Então eu teria que desenvolver um plug-in, e aí… Nada feito.

Aí eu topei com o geany. O geany é uma IDEs leve, multiplataforma, com os recursos básicos de um ambiente de desenvolvimento integrado e cheia de plug-ins. No final das contas, ele é o que eu queria: Uma IDE pequena e rápida, simples, sem muitas firulas. Resolve o meu problema.

Então, como compilar com ele? Bem, para isto você precisa definir que uma das teclas de função, ao pressionar, irá chamar o script que eu citei, para executar todos os passos definidos.

O que fiz foi reprogramar a tecla F8, para que ele chamasse o script. E qual script? Bem, está nesse ZIP aqui. Enchi o código de comentários para facilitar a vida de quem lê. é o script openmsx_compilacao.sh. Seguem abaixo algumas imagens para você ver o que você deve modificar no geany:

Alguns acréscimos…

Uma coisa que eu precisava fazer era entender como automatizar certos funcionamentos do OpenMSX. E o OpenMSX usa TCL para fazê-lo. E eu entendo NADA de TCL. Bem, vamos lá… Com um script em TCL, eu posso dizer pra ele, por exemplo, qual é a imagem de HD que ele irá usar. Então, tateando um pouco, eu fiz o script em TCL fazer o seguinte:

• Setar que o MSX em questão terá uma interface IDE.
• A imagem de disco usada será uma específica, que eu usarei. São 4 partições de 32 Mb cada. Dá e sobra.
• Tudo o que eu irei usar, ficará na 4a partição. Logo, o script formatará essa partição.
• Depois, ele copia tudo de uma pasta específica (a sandbox) pra essa pasta.
• Boota o micro, e como temos a chance de rodar tudo rapidamente, jogo a velocidade do micro em uns 10000%. Sim, um MSX on firah.
• Aí, ele executa o script de compilação, copia o conteúdo da partição de volta pra sandbox e por último, baixa a velocidade do micro para 100%.

Dessa maneira, eu compilo o código no MSX, usando uma velocidade muito maior e tenho o meu trabalho disponível de volta, na pasta em questão.

E funciona. Quer ver o script TCL? Clica aqui.

O resultado: Compilação cruzada usando o OpenMSX, o TP33F e o Linux

Segue aqui um vídeo bem besta, mostrando o funcionamento.

Minha rotina é copiar os arquivos para a sandbox e editar ali. usando o geany. Quando for compilar, basta apertar a tecla programada (F8 no meu caso) e ver a mágica acontecer. Note que o script ainda executa algumas tarefas quando o OpenMSX for encerrado, então não esqueça ele aberto desnecessariamente.

Eu compilo dessa forma, mas quando eu quiser gerar o código final, aí eu abro o TP3 no MSX emulado, e compilo com ele. Fica um pouco menor (não tem o GIOS pendurado), mas não tem longint (infelizmente). Ainda não descobri uma maneira de remover o GIOS, mas ganho um pouco de espaço. O TP33 exige o MEMMAN pendurado, o que me desagrada um pouco. Confesso que não sei como o MEMMAN funciona, então por isso é que eu o acho estranho.

Conclusões e caminhos para seguir

Tratei de comentar bastante os scripts. Como não mexo neles todo dia, é preciso ter bastante comentário para que eu lembre o que fazer, e aonde. Todo o meu pacote está disponível para download aqui. Mas você deve descomprimir uma pasta que te interesse, e é fundamental fazer algumas alterações:

• No script compilacao.tcl, mude o caminho onde está o sandbox. No meu caso, é /home/ricardo/MSX/programacao/dev/sandbox/. Não é preciso mudar o caminho da imagem de HD, o script acha sozinho. Eu já tentei mudar o caminho usando a mesma variável, mas não tive sucesso, sabe-se lá por quê. Se você sabe TCL, me ajude.
• No script openmsx_compilacao.sh, pode ser que algum ajuste seja necessário. Creio que não. Mas na linha onde você chama o openMSX, escolha a máquina que será usada. No meu caso, eu uso a Boosted_MSX2_EN. Mas se você quiser usar um Turbo-R GT, terá que alterar aí.
• Sobre o uso do WebMSX, é perfeitamente possível. Quando eu comecei a fazer essa solução, o WebMSX ainda não existia, mas hoje ele é uma solução muito interessante. Afinal, ele é mais portável do que o OpenMSX (basta ter um link de Internet e um navegador que execute-o), além de ter suporte a coisas interessantes como V9990 e rede… No futuro, devo fazer uma versão para usá-lo também. Se alguém quiser se adiantar e adaptar a solução para ele e depois repassar, agradeço.
• Quanto ao uso do github como repositório de código… Há plug-ins do geany para o github, e eu mesmo estou odiando o git por não entender como fazer ele funcionar.

Acho que é isso. Abrimos uma wiki para documentar e agrupar bibliotecas em Pascal para usar no MSX, nos moldes da wiki que foi feita para a linguagem C. O endereço é pascal.msxall.com. O problema é que só eu a alimento com informações… Sim, precisamos de ajuda.

Agradecimentos.

• Ao povo do OpenMSX, por ter feito um emulador tão fiel e capaz como esse.
• Ao pessoal da MSXBR-L. Alguns ajudaram em alguns momentos, mas não lembro quais. Então vou ficar devendo o nome de todos.
• Ao Fábio Ricardo Schmidlin, que deu alguns toques quanto ao OpenMSX, viu a minha demonstração a respeito e deu a maior força. E também, por ser uma fonte de inspiração para quem resolve rabiscar código para MSX.
• Ao Eliazer Kosciuk, que me perturba há tempos para que esse artigo saia. Viu, KlaxMSX? Saiu!
• Ao PopolonY2K, que forneceu o script TCL que serviu de base, fora algumas conversas interessantes sobre Pascal e MSX.
• Ao Giovanni Nunes, simplesmente por ser fudeba, e pelos pitacos, que são (na maioria das vezes) bem aceitos.