MSX History

Daniel Caetano, conhecido como DJC ou "Fudeba", é um respeitável usuário brasileiro de longa data da linha de computadores MSX. Responsável pela criação de excelentes trabalhos para esta linha de computadores. Realizou diversos trabalhos, 'Breeze', uma tentativa de criar um sistema de janelas para o MSX, 'Fudeba Image Sound Demo', um software capaz de reproduzir uma imagem entrelaçada ou não em Screen 8 e reproduzir sons de arquivos com a extensão .WAV no MSX, 'Fudeba Turbo Changer', software capaz de mudar o estado do Turbo em micros MSX, e, entre os diversos trabalhos já realizados, destacam-se a tradução para a língua inglesa e portuguesa do jogo Snatcher, sensacional trabalho, que permitiu aos ocidentais que explorassem e se divertissem com o ótimo clássico da Konami. Além destes trabalhos, fez a conversão do jogo Shinobi do ZX Spectrum (conhecido como TK90X no Brasil) para o MSX, e agora está envolvido com o projeto Knightmare Gold. Não há palavras para descrever o esforço de criação e desenvolvimento deste seu último trabalho. Knightmare é um clássico do MSX de longa data e acreditamos que todo usuário de MSX sempre quis ver uma versão deste software para modelos de MSX como o MSX2 ou superiores.. O jogo está sendo refeito para o modelo MSX2 e superiores utilizando todas as capacidades gráficas que o MSX2 fornece. Além de outras características únicas, como músicas novas, em CD-ROM. Nesta entrevista que o Daniel gentilmente nos concedeu, conversamos abertamente com ele a respeito de vários assuntos relacionados ao mundo MSX, e entre outros assuntos, conversamos abertamente também sobre o movimento revival que está sendo patrocinado pela ASCII.

Como foi seu primeiro contato com o MSX ?
Foi na casa de um amigo, chamado Gustavo, em São José do Rio Preto. Se não me engano isso foi em meados de 1986.

O MSX foi o seu primeiro microcomputador ?
Oficialmente sim, em 1988,  embora tenha passado um TK-82 pelas minhas mãos antes... mas não era meu, era emprestado. E confesso: eu fazia bem pouco com ele. (^=

Você considera que o MSX foi de fato um computador que iniciou várias pessoas no ramo da informática ?
Sim, embora não seja exatamente o meu caso. Meu interesse por computadores era anterior (meu pai trabalhava com isso) e o equipamento que realmente me despertou interesse para essa "tranqueira" toda foi o Atari 2600. Claro, ele não era programável, mas foi então que eu me admirei com o negócio e comecei a falar no assunto de "fazer jogo". Antes disso eu só me divertia desmontando carrinho de controle remoto e afins. (^= Mas eu acredito que o MSX tenha cumprido este papel para muitas pessoas, visto que foi nele que a experiência de programar realmente se tornou agradável (para mim) e eu comecei a me interessar por fazer mais coisas.

Que tipo de software é possível de ser realizado hoje com um MSX1 ?
O MSX1 permite muitas coisas... ainda mais se tiver periféricos "pendurados" nele. É claro, tem limitações sérias - em especial gráficas - mas muito pode ser produzido. Em especial, eu acredito que para software educacional ele pode ter um papel excepcional. Outro usos bastante legais são controle de dispositivos e demonstrações - os MSX, de forma geral, permitem muitos truques de programação! Ah, claro... jogos! Quantos jogos ótimos não existem para MSX1? (^=

Qual linguagem de programação você recomenda para programação de jogos ?
Depende do jogo e depende do equipamento para o qual você programa. (^= Há jogos que é possível programar, mesmo no MSX, em C ou Pascal. Outros já precisam de um pouco mais de anabolizantes, como a mistura de código Assembly e C ou Pascal... Ou mesmo assembly puro, nos casos mais radicais. Pessoalmente, pela minha experiência, eu prefiro fazer tudo em assembly puro, porque não gosto de lidar com "frescuras" dos compiladores, ao misturar seu código com assembly. Entretanto, isso é uma questão de gosto pessoal. Basta olhar o trabalho do José Lúcio Gama (SLotman) para ver que ótimos jogos são possíveis em Pascal, mistura de Pascal e Assembly e mesmo em BASIC com um pouco de assembly.

A programação de jogos pode ser feita parte no PC e parte no MSX ? Há alguma vantagem neste aspecto ?
Não só pode, como eu seria um pouco taxativo e diria que deve. (^= O MSX é uma ótima máquina pra usar software e para ser programada, mas infelizmente o desempenho dele para programação em si é lastimável, comparado com os recursos que temos hoje no PC. A programação para MSX, quando feita no PC, permite inúmeros recursos indisponíveis na máquina MSX real, tornando o desenvolvimento muito mais prazeiroso. Ao invés de passar horas "tentando saber porque o micro reseta", no PC você pode rodar um debugger e olhar. No PC também é mais simples a criação de aplicativos em alguma outra linguagem (C, por exemplo) para processar dados que você possa precisar no seu programa. No MSX também seria possível, mas um tanto desajeitado (visto que até mesmo o processo de compilação no MSX é muito lento).

O Spectrum utiliza o processador Z80 e tem uma vasta biblioteca de sofware. Como é o grau de complexidade de uma conversão de softwares do Spectrum para o MSX  ?  Pode-se generalizar ou cada caso é um caso ?
O grau de complexidade é alto... em especial porque cada caso é um caso. E, em jogos de Spectrum, cada fase do jogo pode ser um caso. Há muitos jogos - muitos mesmo - em que cada fase tem um programa completamente diferente da outra. Aí, adaptar um jogo se torna, na realidade, adaptar vários jogos. Entretanto, é importante compreender aqui o que significa "alto grau de complexidade": como o hardware do MSX é similar ao do Spectrum (melhor em alguns pontos e, infelizmente, pior em outros, mas bem similar na maioria), a maior complexidade fica em contornar as diferenças, sem que isso prejudique o jogo... porque os jogos de Spectrum, em especial os mais interessantes, usam o hardware "no talo", deixando pouca margem para mexer. Além disso, a maioria dos jogos de Spectrum adaptados para MSX são aqueles do Spectrum 48k - e por isso muitos deles são "sem música" - pois o hardware é mais similar. Para adaptar jogos de Spectrum 128k é preciso um pouco mais de rebolado... tanto que eu não conheço nenhum que tenha sido adaptado. (^=

A Konami criou vários jogos de qualidade para o MSX, para todos os modelos. No caso específico do MSX1, a Konami tem obras de ótima qualidade como Knightmare, The Goonies, King´s Valley e etc. Jogos deste nível são complicados de se criar ?
Sim. Desenvolver jogos de "ação" requer mais do que boa história, gráficos e música. É claro que essas coisas ajudam, mas elas representam um problema sério na hora de programar, no MSX. Muitas vezes, ao colocar tudo operando junto, nota-se que o jogo dá umas travadas, fica com o fluxo descontínuo, etc. É onde entra a necessidade de otimizações malucas para tornar a coisa mais rápida, e onde muitas vezes o programador tem dificuldades. Mas esse não é o maior dos problemas... coisas bem piores como "tentar fazer o jogo para o 'menor hardware possível'", para que todos possam usá-lo, ou ainda "contornar deficiências do hardware" são dores de cabeça bem maiores... só superada por algo que eu considero ser o grande mal de grande parte dos "jogos feitos em casa": lógica de jogo equivocada. Isso pode se refletir em jogo muito rápido ou muito lento, personagem com movimento "jerky" ou "the flash", inimigos impossíveis de serem contornados, etc. O jogo pode ser lindo, ter uma história maravilhosa, contornar todos os limites do hardware e usar recursos incríveis... se a movimentação e o controle do jogo forem ruins, o jogo será ruim. E, infelizmente, muitos dos autores "caseiros" não olham para este aspecto, desperdiçando enormes esforços em todas as outras áreas do jogo ao implementar uma jogabilidade ruim... talvez por não existir um "controle de qualidade". Neste aspecto fico feliz pelo desenvolvimento do Brasil. Tirando ZORAX, acho que a maioria do que foi produzido aqui - em termos de jogos - tanto pelo José (SLotman) quanto pelo Ricardo (RicBit), bem como alguns autores antigos de Adventures, são muito bem balanceados. É pena que a produção de jogos nacional seja pequena.

Ainda comentando sobre o assunto acima, pode-se criar jogos com este nível de qualidade apenas usando a linguagem Basic, nativa nos MSX, ou se não, somente o Assembly seria o ideal ou poderia ser considerado também Pascal ou C ?
Como disse antes, depende do jogo. Eu diria que, em termos de jogos, apenas Assembly é "panacéia", ou seja, é o único que "resolve todos os problemas"... embora isso muitas vezes signifique que o programador é quem terá de resolver 100% dos problemas. Entretanto, em assembly você dificilmente esbarra com dificuldades insuperáveis (como travamentos inexplicáveis por causa de uma rotina de interrupção "que não faz nada de errado"). Ainda assim, para muitos tipos de jogos, C, Pascal ou BASIC também resolvem. Hoje em dia eu diria que, das linguagens de alto nível, o Pascal é o mais indicado, não só pelo resultado que já vi sair das mãos do José (SLotman), mas também pelas bibliotecas disponíveis.

Imaginamos também que grandes empresas como Konami, Namco, Taito, deviam fazer uso de alguma ferramenta de desenvolvimento, para facilitar o trabalho de criação de software, talvez até mesmo como um editor de fases, trabalhando em conjunto com um editor de gráficos, editor de sons, ou seja uma espécie de 'kit de ferramentas' para o desenvolvedor. E, pensando ainda neste 'kit', talvez, esta não seria uma solução prática para facilitar o desenvolvimento de novos softwares, pensando até mesmo em desenvolver fases, gráficos e sons fazendo uso de uma ferramenta no PC e juntando todas estas peças utilizando programação no MSX. O que você pensa a respeito ?
De certa forma, sempre que desenvolvemos algo pra MSX - seja algo 'do zero' ou alguma alteração - desenvolvemos ferramentas que auxiliem no desenvolvimento. Entretanto, embora algumas destas ferramentas sejam genéricas e sirvam para outros jogos, a maioria é muito específica. Isso ocorre porque os jogos de MSX, em geral, exigem uma otimização tal que tornam "soluções genéricas" inapropriadas. No desenvolvimento da tradução do Snatcher, do Shinobi, do Knightmare Gold e mesmo em outros projetos que não viram a luz do dia (ao menos ainda) eu desenvolvi diversas ferramentas, como o MSXDASM, o BIN2MAC, o PAT2ASM, o TOSKRLE, dentre outros. Quando sobra um tempo, eu dou um tapa neles, faço um pequeno help explicando como usa, compilo pra diversos SOs e libero. Entretanto, muitos outros utilitários (como o SNATCHPATCH) é muito específico e não faz sentido ser liberado. Há um tempo atrás eu perdi um tempo numa versão um pouco mais genérica do SNATCHPATCH, uma espécie de Disk Patcher, voltado à tradução de jogos, mas ainda não tive tempo de terminar. Resumindo: é interessante, SIM, ter kit de desenvolvimento... mas é difícil dizer o que colocar nele. De uma forma geral, nós que desenvolvemos e nos mantemos em contato um com o outro, comentamos uma necessidade sempre que precisamos de algo. Se alguém já tiver feito algo parecido, passa o fonte e a gente faz as alterações necessárias. Ademais, temos editores de programação como o MSXPad do SLotman, o conversor de imagens do Marcelo Silveira, o emulador do Ricaro Bittencourt... enfim, ferramentas para programação não faltam. Só que programar não é aquilo que se faz hoje em dia com Delphi e VB, "colando blocos". (^=

Quais vantagens você vê de um MSX2 sobre um MSX1 ?
Muitas, é verdade. O V9938, com os screens 4 a 8, sprites multicoloridos e blitter, somados à definição do padrão Memory Mapper como expansão de memória tornaram o padrão MSX muito mais poderoso e capaz de software (em especial: jogos) muito mais bonitos, tornando a máquina muito mais atraente. O ponto chave foi a ampliação dos recursos, mantendo a simplicidade da máquina. As coisas que mais faziam falta ao MSX2, no meu entender, eram o scroll suave horizontal (e sua máscara de tela), bem como a possibilidade de utilização do blitter nos modos "baixos" (do MSX1) e controle de velocidade de escrita no VDP, para que os programas já no MSX2 não precisassem se preocupar (tanto) com o timing de escrita no VDP. Ah, e claro, desde essa época, a manutenção da velocidade do Z80 a 3.57MHz foi um erro, por três razões: 1) já existiam Z80s mais rápidos, não precisava nem "inventar" algo novo. 2) Deixou os programadores mal-acostumados, sincronizando jogo por timing de CPU, bem como desenvolvedores de hardware, que faziam hardware sempre pensando em clock de 3.57MHz,  o que causou sérios problemas no futuro (obrigando-nos a usar slot externo de 3.57MHz até hoje, por exemplo). 3) O Z80 começou a ficar em descompasso de velocidade com as grandes massas de dados que eram necessárias transferir para o VDP, ao mesmo tempo em que ainda precisava fazer todo o resto...! É claro que, ao trocar o Z80 por um mais rápido, seria interessante ter adicionado um timer especial para sincronia de software, talvez até ligado na NMI (que nunca foi usada no MSX). Tal timer não seria um grande custo adicional e teria sido um recurso muito importante.

E sobre o MSX2+, qual sua opinião sobre este hardware ?
É um hardware um tanto tosco para ser considerado uma nova geração... tanto que os japoneses só colocaram um "+" no nome. (^= Na minha opinião, o MSX2+ é apenas algo mais próximo do que o MSX2 deveria ter sido, já que o único feature realmente "killer" que ele apresenta é o scroll fino horizontal, algo que teria possibilitado que jogos como Contra e Vampire Killer, da Konami, tivessem scroll horizontal, ao invés de telas estáticas toscas. Tirando isso, Screen 10, 11 e 12 tornaram-se quase que meras curiosidades (existem algumas gratas excessões). A Screen 10 ainda serve para brincar um pouco, em especial para Adventures e RPGs. Infelizmente a maioria destes recursos foi usada por um número muito pequeno de jogos e, mais infelizmente ainda, um número muito reduzido de pessoas tem MSX2+ no mundo... o que nos faz pensar 200x antes de programar um jogo específico para MSX2+. O padrão MSX2+ teria sido muito mais interessante se adicionasse alguns modos tiled com cor pixel a pixel, bem como sprites coloridos pixel a pixel (ao invés de linha a linha). Tivessem sido adicionadas essas "features", além daquelas já citadas para o MSX2, o MSX2+ certamente teria sido muito mais atraente do que foi... e poderia até ter se chamado "MSX3". (^=

Turbo R, é o melhor modelo para você ?
(rs) Melhor para quê? Ele é praticamente um MSX2+ com uma CPU rápida. Sim, o R800 é muito legal. Sim, eu gostaria de ter um Turbo R - até programaria específico pra ele, se tivesse - mas não tenho condições financeiras de gastar em um o que pedem por ele. Acho que talvez existissem outros investimentos mais interessantes, como  uma GFX9000 ou um HBI-V1, dois periféricos que eu gostaria de ter e não tenho. Então, sim, é o melhor MSX já fabricado... mas, infelizmente, não com grande estilo.

Há vantagens e melhorias quanto a desenvolver softwares com um Turbo R, isto é, o que pode ser feito a mais com um modelo destes ?
Bem, sem dúvida é possível desenvolver algumas coisas mais interessantes no Turbo R, mas a grande parte das possibilidades são abertas pela maior velocidade, ou seja, nada que um MSX2+ mais rápido não seria capaz. Falando um pouco de features interessantes dele, é possível fazer jogos mais elaborados, com áudio digital nos efeitos e coisas do tipo... Mas fica meio por aí. O mesmo VDP tosco do MSX2+, falta do DMA (de RAM e, talvez, VRAM), falta de um PCM inteligente (similar ao da Music Module), a não possibilidade de usar as duas CPUs ao mesmo tempo (paralelamente), dentre outros problemas, comprometem muito "o que poderia ser feito com um Turbo R", ao meu ver... e comprometeram seu sucesso (tanto que a linha morreu nele: ele não conseguiu concorrer com outras linhas da época). É importante ressaltar que eu certamente o considero o melhor MSX feito, mas ele não é tão bom quanto poderia ter sido... com o mesmo hardware que já tem ali dentro da caixinha, e isso é lamentável.

Memória de vídeo do MSX parece sempre ser um impecilho no desenvolvimento de novos softwares no MSX, você concorda ?
SIM! Em especial para os modos de vídeo Screen 7 para cima. A ausência de espaço pra framebuffer *e* armazenagem de shapes torna o Blitter - uma das grandes vantagens do 9938 e superiores - bastante limitado nestes modos, fazendo com que o próprio uso destes modos seja limitado. É por isso que eu quero ter 192K de VRAM no meu MSX. Não é tudo que eu poderia desejar (alguém por aí falou ADVRAM? =^), mas já quebrava um bom galho para brincar nos "screens mais altos".

Há como desenvolver jogos para a MegaRAM (a MegaRAM é um periférico desenvolvido por Ademir Carchano, no Brasil e é uma alternativa a Memory Mapper) ? Certamente que sim. Aliás, existe até um boato que o cartucho SCC+ (que não deixa de ser uma mini-megaram, também) era o equipamento de desenvolvimento da Konami... Se eles usavam algo assim há 20 anos - e certamente usavam, não fazia sentido ficar gravando EPROM o tempo todo pra testar jogo - qualquer um pode usar. (^=

A MegaRAM, não seria uma boa alternativa para criar jogos no formato MegaROM, pergunto isto pois tem se cogitado criar MegaRAMs com até 2MB ou 4MB de memória através de chips SIMM. Pode-se fazer uso real desta alternativa ?
Sim, eu diria que sim. A questão que fica aqui é: porque criar jogos MegaROM hoje, se a maioria dos usuários possui pelo menos uma unidade de disco? Sim, MegaROM permite algumas "firulas" que em um jogo de disco ficariam meios desajeitadas, mas há de se lembrar que a confecção de um jogo MegaROM - ou mesmo um cartucho MegaRAM - não é "de graça", e poderia limitar a quantidade de usuários do produto.

Não existe 'uma API' para desenvolvimento fazendo uso dos recursos da MegaRAM. Você considera que este esforço valeria a pena, considerando o aspecto da questão anterior ?
Não sei. MegaRAM é algo que é difícil usar em C ou Pascal (e também em BASIC) puro... Mesmo com uma API, não seria a coisa mais prática do mundo para se programar (serviria, primariamente, para guardar dados). Já em assembly, onde é possível usar todo o potencial da MegaRAM sem muita dor de cabeça, a programação é trivial o suficiente para não exigir uma API. Entretanto, a história de adaptar o MEMMAN para operar também com a MegaRAM tem rondado por aí já a algum tempo... nunca se sabe o que pode surgir amanhã... (^=

Você prefere para desenvolvimento: Memory Mapper ou MegaRAM ? Há alguma razão específica ?
Memory Mapper. Além de ser um periférico mais difundido - até por ser o padronizado, a Memory Mapper é mais fácil de programar (na minha opinião).

Você prefere para jogos: Memory Mapper ou MegaRAM ?
Depende do jogo. (^= Jogos de MegaROM ficam BEM melhores em MegaRAM. Jogos de mapper... bem, não conheço nenhum programa que os façam rodar em megaram. (^=

É possível emular o SCC através do MSXMusic ou FM-PAC ? Ou seja, ouvir os sons dos jogos SCC fazendo uso do hardware do MSXMusic e de um software capaz de utilizar os recursos de hardware do MSXMusic para simular sons do SCC ?
Bem, OPLL e SCC não são bem a minha área - meu conhecimento em programação de som é bem limitado - mas, dado que o MSX Musica (OPLL) tem o "dom" de reproduzir sons digitais, embora de baixa resolução, sim, seria possível emular o SCC através dele. Com alguns truques talvez também fosse possível simulá-lo com a própria síntese FM, mas o resultado não seria lá muito bonito. Em ambos os casos, o custo de processamento pode inviabilizar a brincadeira - a menos que o áudio seja convertido a priori, mas aí ... basta transformá-lo em WAV e até o PSG o reproduzirá. (^=

Com o suporte a periféricos como CD-ROM, DVD-ROM, através da IDE, acreditamos que muito software bom pode ser desenvolvido para MSX1, 2, 2+ e Turbo R, inclusive com músicas cantadas, trechos de filmes, podendo fazer um bom uso desta tecnologia. O que você pensa a respeito desta possibilidade ?
Eu acredito que é uma grande área que ainda foi muito mal explorada no MSX... talvez até pelo baixo índice de pessoas com IDE no MSX. Entretanto, ainda é possível comprar IDEs para MSX por preços relativamente aceitáveis, então eu acho que vale a pena investir nisso. O Adriano Cunha (UZIXman) e o José Gama (SLotman) foram pioneiros no uso deste tipo de recurso no MSX, e acredito que é uma ótima via a ser seguida... em especial por programadores que, como eu, possuem dificuldade com a produção de músicas - ainda mais com as limitações do MSX - pois se as músicas estão no CD, não só a programação é mais simples, como também é possível usar qualquer música em seus programas/jogos.

Conversando um pouco a respeito dos trabalhos que você criou, o Breeze, qual o objetivo deste software ? Hardware é a principal carência para que este sistema se torne uma realidade ?
O objetivo do Breeze era criar uma interface gráfica de verdade para MSX. É importante lembrar aqui que uma GUI não é um "file browser". Uma GUI é um subsistema inteiro que fornece uma API com o objetivo de executar programas que usem esta API, permitindo inclusive que eles interajam... ou seja, é um conceito mais amplo, que visa facilitar o desenvolvimento de aplicações com interface gráfica - incluindo aí um file manager. Sobre a principal carência, sim... a principal carência é hardware, ao menos para que ele pudesse ser executado numa Screen 6, com uma resolução de 512x212, que eu considero a resolução minimamente aceitável para uma GUI genérica. O hardware é o limite, neste caso, porque uma GUI não tem que ser apenas "fácil de usar e bonitinha", mas também tem que ser minimamente ágil. E é nessa hora que, mesmo com programação totalmente em ASM e usando todos os recursos de aceleração do V9938 ou 58, a coisa fica inviável: fica lento demais para ser considerado útil. Quando ví que a coisa ia ficar realmente lerda - e que ia me tomar anos de uma programação que não ia me agradar o resultado - eu abandonei o projeto. Hoje penso que alguém poderia fazer uma "GUI" baseada em texto, como o Like do Giovanni Nunes. Não é a solução mais bonita do mundo, mas é preciso reconhecer que talvez seja o melhor que o MSX sabe fazer, com o hardware atual.

O que é o Fudeba Image Sound Demo ? Reproduz a músicas de arquivos WAV no MSX ? Precisa de FM-PAC ou SCC ?
O Image Sound Demo é um dos muitos programas que eu desenvolvi como teste e base para outros projetos e não... ele não precisa nem de FM ou SCC: usa PSG apenas. Na época em que o desenvolvi, eu estava criando rotinas prórpias que transferissem imagem do disco para a VRAM, em assembly, e também entendendo como funcionava o READWAV do Ricardo Bittencourt. Aí, surgiu a idéia de fazer um pequeno utilitariozinho que unisse as duas funções e liberar seu código fonte, para que outras pessoas pudessem ver como aquele tipo de coisa poderia ser feito. Eu sempre tenho interesse em passar o pouco conhecimento que eu tiver para quem quer que se interesse em produzir algo. E isso não é diferente com relação ao conhecimento de MSX.

Você está, ao longo do tempo, desenvolvendo o Curso Prático de ASM. Como surgiu a idéia de escrevê-lo ?
Bem, de uma certa forma eu sempre tive vontade de escrever tutoriais de linguagens de programação. A idéia não surgiu com Assembly, mas com a linguagem C. Entretanto, eu sempre esbarrei em uma dificuldade: definir o público alvo. Quem quer aprender C hoje em dia? Ora, tem um monte de gente, mas também existe uma infinidade de materiais para ensinar isso. Foi assim que pensei no público alvo do MSX... mas, pensando em MSX, C não é a melhor solução do mundo - sequer eu tenho prática com C no MSX.
Foi assim que eu migrei pra idéia de um tutorial de assembly, pois sempre ouvia as pessoas dizerem que tinham tentado aprender assembly mas não tinha conseguido. Bem, é normal isso. Os livros e tutoriais que existem são muito pouco práticos. Para quem já tem "manha" de programar, são ótimos, mas para quem está começando, acaba sendo um pouco árido. Por exemplo, ficar falando de lógica booleana e álgebra binária logo nas primeiras aulas não é o que eu chamaria de "didático", quando o curso pretende quem tem pouca experiência com programação. Com base nisso e na lembrança de como aprendi C pelo livro do Schildt, resolvi escrever um curso de ASM nos moldes de um curso prático de C. E o resultado é este que está saindo... aos poucos, mas está.

A quem é destinado o Curso Prático de ASM ?
A quem quer aprender a fazer de tudo com o MSX, seja ele experiente em programação ou não. O curso tem uma dinâmica um pouco difícil, algumas aulas são bem mais complexas que outras... mas isso é um pouco inerente à linguagem assembly: a curva de aprendizado é alto. Entretanto, nunca pretendi tornar assembly uma linguagem fácil - não tem como - mas sim tornar o aprendizado menos teórico, menos "matemático" e mais "prático". Isso porque acredito que nenhuma linguagem de programação se aprende lendo, mas sim exercitando. Um curso prático contribui para isso: o exercício. Uma das maiores dificuldades que tive, quando eu aprendi assembly... há muitos anos, foi exatamente de partir da teoria que tinha aprendido... para a prática. Com o tempo me adaptei, claro... mas não consegui deixar de pensar que tinha aprendido do jeito errado... porque depois que peguei prática, fiquei pensando: "Poxa, mas isso não é tão diferente do Basic...porque raios tive tanta dificuldade?"... E a resposta, depois de anos pensando no assunto, foi ... "eu aprendi do jeito errado". Não se deve aprender as primeiras linguagens de programação pela especificação - como a maioria dos livros de assembly faz - mas sim pelo uso. Depois que você souber fazer alguma coisa com aquilo, você aprende a especificação... para se aprofundar. Isso pode parecer um absurdo para alguns, mas a verdade é que, para a maioria das pessoas, aprender a programar já é algo árido o suficiente por si só... e a forma usual de explicar "loooooooonga teoria" + "prática rapidinho" só contribui para piorar as coisas.

Qual leitura adicional ao curso você recomendaria ?
Para quem chegar até uma aula como a 6 ou 7 - compreendendo o conteúdo - basta pegar um livro como o "Linguagem de Máquina MSX", do Rossini e Figueredo, e aprender mais instruções, mais operações. Com alguma prática nisso, pode-se pegar o MSX Top Secret do Edison Pires e aprender mais sobre o MSX... E aí ninguém mais segura (rs). O livro do Rossini é mais "arcano", parte pro lado mais tradicional do ensino. Entretanto, depois de já ter visto um pouco de como se usa a linguagem de máquina para fazer um programa, ele se torna mais "digerível", mesmo para os iniciantes.

Além do brMSX há algum outro emulador que se possa utilizar para depuração de códigos ASM ?
Vários. Até os fMSX mais novos possuem essa opção. Eu só não os cito no curso porque não tenho prática com eles, uma vez que uso apenas o BrMSX.

Pode nos dizer se os jogos da Konami foram todos escritos em ASM ?
A impressão que passa... é que sim. A aparência é de que eles usavam alguma macro-linguagem para facilitar o desenvolvimento e tudo o mais, *mas* muitas das estruturas são inconfundivelmente feitas à mão. Nenhum compilador (ao menos daquela época e pra um processador CISC) gera código tão "limpo", digamos assim. :)

Pudemos observar que através da depuração de um código ASM, pode-se encontrar literais dentro do código. Pensando assim, seria possível, através do conhecimento de ASM, efetuar a tradução de softwares ?
Sem dúvida. A tradução de softwares antigos, quando feita por quem não entende a linguagem em que o software foi programado, tende a ser mais pobre. Isso ocorre porque muitas vezes é necessário corrigir o comportamento do software para a outra língua, coisa que só pode ser realizada com alteração do código. Caso contrário o tradutor pode ficar atado a limitações bestas, como não ter acentos para as palavras, exigir seqüências malucas para a entrada de dados, etc.

Quanto tempo tem levado em média para escrever uma aula, levando em consideração a complexidade do assunto, extensão, etc ?
Depende muito da aula. As aulas mais curtas eu acho que dá pra escrever numas 5 ou 6 horas. A aula 7, a mais longa até então, eu levei umas 15 horas escrevendo (e reescrevendo). Umas 5 no primeiro dia que a peguei para escrever (há uns 6 meses... rs), 5 horas na véspera de eu liberá-la e mais 5 horas no dia em que a liberei. O trabalho de escrever a aula não é apenas de escrever um algoritmo (até agora, não aproveitei nada que já tivesse nas aulas, é tudo reescrito do zero), mas também em pensar uma forma didática de explicar o que está sendo feito, introduzir os erros (comuns) propositalmente para ajudar a explicar como depurar - e familiarizar o leitor com as correções de erros comuns... às vezes envolve reescrever partes inteiras, para melhorar a didática, introduzir comentários no meio para detalhar algum truque... e claro, testar tudo para que os códigos não dêem problema quando o leitor for executá-lo.

Pode-se juntar ASM com outras linguagens para desenvolver um software, isto é, pode-se desenvolver usando C, Pascal, e até mesmo Basic, fazendo uso também do ASM ?
Sim. Você pode ter trechos em ASM dentro de outra linguagem e até pode usar coisas de Basic, por exemplo, dentro do ASM. E isso é mais comum do que se pensa. A maioria dos bons programas BASIC possuem trechos em Assembly... e muitos programas em C e Pascal possuem grandes trechos de código "assembly inline". Na aula 8 eu devo tratar um pouco sobre este tipo de integração, entre assembly e BASIC. Vamos ver quando eu vou ter algum tempo para escrevê-la. :)

O curso atualmente está na aula 7, que trata de cálculos matemáticos, mais especificamente em relação as divisões em ASM. Quais são os temas das próximas aulas ?
Eu tenho um guia aqui, mas eventualmente eu terei de "expandir" algumas aulas em mais aulas (isso já aconteceu com a 5, 6 e 7, que originalmente eram um único tópico, e eu transformei em 3 aulas). Os tópicos que planejei inicialmente para as aulas seguintes são:

Aula 8: Ingrando Basic com ASM I (Passagem de variaveis)
Aula 9: Programando o VDP I (Conhecendo o bichinho e mostrando desenhos)
Aula 10: Programando o PSG I (Conhecendo o bichinho e tocando musiquinha exclusiva)
Aula 11: Trabalhando com arquivos no MSX-DOS (Abrir, fechar, fudebar)
Aula 12: Truques de Programacao I (Diversos, DJNZs pra frente, Jump Tables e coisas do genero)
Aula 13: Programando o VDP II (Animacao e modos especiais)
Aula 14: Integrando Basic com ASM II (Funcoes do usuario)
Aula 15: Expansoes de Memoria I (Trabalhando com Memory Mapper)
Aula 16: Truques Matematicos IV (Operacoes logicas para imagens)
Aula 17: Programando o VDP III (Comandos do VDP)
Aula 18: Expansoes de Memoria II (Trabalhando com a MegaRAM)
Aula 19: Interfaces de Comunicacao I (Joysticks/Joynet)
Aula 20: Programando o FM I (Audio exclusivo)
Aula 21: Truques de Programacao II (Interrupcao e Hooks)
Aula 22: Programando o PSG II (Audio sincronizado)
Aula 23: Programando o FM II (Audio sincronizado)
Aula 24: Programando o VDP IV (Screen Split)
Aula 25: Trabalhando com arquivos no MSX-DOS 2 (Abrir, fechar, fudebar)
Aula 26: Trabalhando com o Mouse
Aula 27: Interfaces de Comunicacao II (Impressora)
Aula 28: Acesso direto ao Disco
Aula 29: Truques Matematicos V (Compressao de dados)
Aula 30: Modificando um Programa I (Desassemblagem)
Aula 31: Modificando um Programa II (Estruturacao do Ambiente de Trabalho)
Aula 32: Modificando um Programa III (Reassemblagem e Patching)

Qual o escopo que pretende atingir com o Curso Prático de ASM ?
Eu pretendo que as pessoas que o lerem com atenção, fizerem os exercícios e tirarem suas dúvidas... sejam capazes de fazer aquilo que elas bem entenderem com seus MSX... e até que tenham caminho tranquilo para a linguagem de máquina de outras plataformas. Se vou conseguir... aí já é uma história totalmente diferente... :)

Vamos falar um pouco a respeito do movimento MSX Revival. O que você pensa a respeito do que foi feito até agora ?
Olha, é complicado falar disso. Eu ainda não vi até onde eles estão dispostos a ir, mas tudo que eu poderia dizer é que, com relação ao que eles têm feito até agora, minha impressão é das piores. Eu sei que há pessoas com real interesse em que a coisa dê certo, que realmente têm boa vontade e tal, mas a coisa toda está sendo muito mal conduzida e, como resultado, ficou apenas esta aparência de "caça-níqueis" para o projeto todo.

Qual a sua expectativa com relação ao MSX Revival  ?
Eu realmente espero que dê certo e transformem algo parecido com um MSX (que siga pelo menos sua mesma filosofia) em algo comercialmente rentável. Infelizmente não tenho muita confidência que esse objetivo será atingido.

O que você gostaria de ver no novo MSX ?
A mesma filosofia do MSX original: uma máquina relativamente barata,  fácil de programar para os usos e interesses do dia-a-dia, incluindo aí entretenimento. Isso tudo em um hardware mais atual, obviamente.

Falando francamente, não seria melhor para todos nós usuários da comunidade MSX ver um MSX3 de uma vez, um hardware novo, compatível com o antigo, e com características novas ?
Eu não tenho a menor dúvida. Aliás, essa era a proposta do CIEL3++. Infelizmente a coisa não andou no passo que era desejável e hoje estamos à mercê de sei lá quais interesses da MSX Association. Entretanto, ainda resta a esperança no equipamento do DalPoz. Ainda é um MSX1, mas depois pode vir a ser um MSX2, 2+ e eventualmente ter extensões bastante interessantes. Não deve se tornar um produto comercial como um MSX, mas eu não acharia nem um pouco estranho ter um "MSX" like dentro de um DVD-Player, como seu controlador. Como efeito colateral, poderíamos usá-lo para "brincar" em casa.

O MSX tem bastante público, isto, se somarmos toda a base de usuários pelo mundo todo. Você acredita (se a ASCII levar este projeto MSX Revival adiante, levando em consideração a opinião dos usuários e não somente a visão deles), que este projeto possa a vir ter sucesso ?
Eu acho que sim, mas o direcionamento tem que ser outro. Eles corretamente não posicionaram o produto como um concorrente do PC, entretanto, na minha opinião, erraram feio ao voltá-lo somente ao mercado japonês e, em especial, em não ouvir a comunidade. E aqui não se trata de opinião do tipo "como vocês querem seu MSX", mas sim coisas mais técnicas, mesmo. A comunidade passou mais tempo programando pra MSX do que qualquer um da MSX Association e, certamente, conhece melhor quais limitações e dificuldades da plataforma que precisam ser superadas, para que possam ser produzidos software de maior qualidade. Um outro ponto é que, acredito, a decisão do hardware também foi equivocada. Eu acredito que o hardware de um novo MSX precisaria ser "custom", mesmo a CPU, para fornecer um módulo de compatibilidade e, ao mesmo tempo, um modo extendido... talvez até num esquema "Virtual MSX" - não emulado, mas baseado na mesma idéia das seções V86 dos processadores i386 e superiores.

Você acha também que o material (seja lá este material de hardware, software e revistas) vindo da ASCII e do Japão devem vir em duas línguas (japonês e inglês), facilitando e incentivando e muito a aquisição por parte de todos interessados ao redor do globo ?
Certamente! E diante de uma eventual não possibilidade em produzir em duas línguas, que fosse feito apenas em inglês! Pode parecer absurdo, mas se é pretendido ter sucesso comercial com um produto cuja maior base de usuários está fora do Japão, eles não podem se basear apenas no consumismo japonês para sustentar este produto.

O que você pensa do Cart Reader da ASCII ?
Mera curiosidade.
 
Você acredita em outras iniciativas, vindas de outros meios que não sejam por parte da ASCII ?
Sim, sem dúvida. Mas dificilmente algo que torne o MSX um produto comercial novamente.

Um novo MSX brasileiro ? Periféricos brasileiros ?
É uma questão de alguém se interessar e fazer. Idéias sempre existem aos montes. (^= Mas, infelizmente, são poucas as pessoas têm a possibilidade de colocar seu tempo em uma atividade que não gerará nenhum lucro significativo. )^=

Recentemente foi feita uma pesquisa para avaliar uma possível iniciativa de desenvolvimento de um MSX aqui no Brasil. Pelas características e resultados colhidos na pesquisa, teve-se definido como padrão para um possível desenvolvimento o hardware do MSX2+. O que você pensa a respeito desta iniciativa ?
Eu acho interessante, mas não muito mais do que isso. De uma especificação até um produto final tem uma distância muito grande, que aumenta ainda mais quando o número de pessoas trabalhando é reduzido e os recursos são praticamente inexistentes. Eu acho isso triste, não me sinto confortável com essa situação.

Conversando um pouco sobre emuladores e MSX reais, você utiliza emuladores ? Com que finalidade ?
Sim, uso emuladores. Basicamente os uso para teste inicial de programação, debugging e teste final.

Qual emulador você prefere, porquê ?
BrMSX. Porque ele roda em DOS (e eu consigo rodar ele no meu sistema operacional) e o debugger dele é muito bom. OpenMSX seria uma opção, se eu tivesse sido capaz de portá-lo para o meu sistema... mas não consegui.

E qual você considera obsoleto ?
Vários, mas o fMSX é um que despencou no ranking de qualidade... mas, mesmo assim, acredito que ele tem um lugar especial. Afinal, o fMSX foi praticamente o emulador que iniciou a "febre"... (rs)

Emuladores X MSX Real ?
Não tem como competir. Na minha visão são coisas diferentes. Emulador é uma ferramenta de desenvolvimento. O jogador causal - ou aquele que não tem espaço pra colocar um micro real - pode usar um emulador e ter até algumas vantagens com isso - como o save state - mas não se compara ao equipamento real. No entanto, para testar programação, o emulador é muito mais confortável, na medida em que traz o debugger e, no caso do BrMSX, por exemplo, tem o recurso de acelerar a execução, o que é bastante agradável em muitos casos.

Conversando um pouco sobre desenvolvimento de software, que software você gostaria de ver no MSX ?
Um adventure no estilo Monkey Island, do PC.

E qual software você gostaria de fazer para o MSX, por pura diversão ?
Um adventure "das antigas", com recursos disponíveis nos MSX mais avançados.

Gradius é bem legal, achamos que seria um sucesso uma nova versão para MSX2 ou MSX2+... o que acha ?
Pode ser uma boa pedida. Mas bem... fale com o Fábio (FRS) ... (rs) Ele já fez uma parte disso pro Nemesis. (^=

Hinotori traduzido para o inglês e português....não? Sim?
É um bom jogo, e não acho que tenha tanto texto assim... Se alguém se interessar em fazer, a gente sempre ajuda. (^=

E já que tocamos no assunto de tradução... isso nos lembra:.Snatcher (veja mais em: http://www.caetano.eng.br/snatcher) . Daniel, seu trabalho foi excelente, é preciso que isto seja dito. Você pode ter a certeza de que muitos ocidentais só tiveram a oportunidade de jogá-lo graças ao seu trabalho. E falando sobre isso, como é traduzir um jogo grande como o Snatcher, tudo em japonês para outra língua ?
Primeiramente, obrigado. Eu não considero o trabalho do Snatcher completo, ainda que seja perfeitamente jogável até o fim - ainda há correções de texto a fazer... e talvez algumas melhorias, mas ainda não tive tempo e paciência para terminá-lo. Quanto à tradução, no caso do Snatcher foi... angustiante. O jogo era tão amarrado na língua japonesa - em diversos aspectos - que eu tive que fazer mudanças radicais em muitos dos trechos do código, ampliar a linguagem script do jogo para incorporar novas funções e tudo o mais... Você pode estar se perguntando porque isso tudo deixaria alguém angustiado. Bem, é simples... Quando se altera um código que não é seu, você nem tem idéia de todas as conseqüências que esta alteração pode trazer. Algumas alterações que você faz parecem funcionar bem, mas posteriormente adicionam problemas no próprio jogo, e nem sempre é possível relacionar facilmente uma coisa com outra. Depois de vários meses programando todos os dias, você pensa que o trabalho de codificação acabou... Mas ao prosseguir no jogo, descobre que tem algo incompleto ou funcionando errado, e tem que "voltar pra prancheta"... E, às vezes, ao fazer isso, descobre que pra corrigir o problema, terá que mudar toda a lógica da sua alteração, refazer um bom pedaço do trabalho... e pior: você não sabe se com toda essa alteração não vão aparecer mais problemas, até mesmo em lugares que estavam funcionando bem antes! (rs) Isso torna o teste do software um pesadelo e, pra piorar a situação, começa a dar um desespero de imaginar que talvez surja algum tipo de problema na tradução que não seja possível contornar e, impossibilitando o término da tradução, você tenha jogado anos de trabalho no lixo...

Mais alguém participou do trabalho de tradução ?
Definitivamente, sim. (^= A extração do texto original foi de Artemio Urbina, do México. Embora não tenha sido uma extração completa, ele extraiu 99% do texto do jogo, por assim dizer. Com base neste texto, Takamichi Suzukawa traduziu para o inglês - com comentários para que algumas das piadas pudessem ser compreendidas. Com base nisso, comecei o processo todo de tradução, para extrair o script completo (com textos e comandos do jogo) e criar o resto do código. No meio deste processo o Dante Nishida (atom) também contribuiu bastante, identificando as figuras no código do jogo e traduzindo várias delas. Muitas outras pessoas participaram também, não lembro de cabeça, em re-traduções e interpretação dos textos do Takamichi, bem como na criação de versões "nacionais" das piadas... de memória eu lebro do Leandro Pereira (acidx), Reinaldo Quaresma (Barnabé), José Gama (SLotman), Ricardo Bittencourt (RicBit), dentre outros do canal #MSX da Afternet. O Adriano (UZIXman) contribuiu com dicas na programação e as reclamações constantes do Ginseng deram toque de "controle de qualidade" (rs).

A tradução foi seguida literalmente, ou houve alteração nas frases ?
Depende. A versão em português foi bem isso: uma versão. Todas as piadas foram adaptadas para serem compreendidas por habitantes do mundo MSX do Brasil, já que as piadas originais são muito específicas da cultura japonesa. Aliás, este é um dos pontos que eu ainda preciso mexer no Snatcher em português: tornar as piadas genéricas até mesmo para quem não é do mundo MSX do Brasil. A versão em inglês, por sua vez, é quase que o texto do Takamichi na íntegra (e portanto, literal). Eu mexi o mínimo possível para que o texto pudesse caber no espaço que eu julguei adequado. Este texto precisa de muita correção, não só na parte que eu mexi, mas também no resto todo. Várias pessoas (mais de 10) já se propuseram a corrigí-lo, mas quando eu envio o arquivo com cerca de 10.000 diálogos... acho que a pessoa perde um pouco o interesse, porque ninguém até hoje devolveu o texto corrigido.

Você utilizou alguma ferramenta para traduzir, pode nos contar como é feito este processo de tradução para que pessoas que tenham vontade de se tornar tradutores de jogos tenham como base um ponto de partida ?
Eu usei várias ferramentas, mas a maioria eu mesmo desenvolvi para o próprio processo de tradução. Além dessas, usei também o BrMSX e um editor hexadecimal HEDIT (hoje substituído por mim pelo Kon Editor). O processo, no caso do Snatcher, foi um pouco diferente do método de tradução usual. Primeiro eu fui desassemblando o jogo para entender como ele se estruturava na memória do micro. Depois que entendi e saquei onde estava as rotinas principais de vídeo, tratei de alterá-las para que caracteres de um byte pudessem ser escritos, ao invés de caracteres japoneses, de dois bytes. A partir daí, comecei a tentar entender o script do jogo, para conseguir desenvolver uma ferramenta que fosse capaz de extrair todo o script do jogo. Quando a primeira versão disso estava pronta, comecei a mexer nos textos, os quais inseria de volta no jogo e, quando necessário, ia adicionando novas rotinas no código, como a rotina necessária para textos maiores que os originais, a rotina de entrada de caracteres e coisas do tipo. Tirando os "pepinos" de programação, o trabalho é praticamente braçal.

O trabalho de tradução envolve muitas outras coisas a mais do que simplesmente pegar um texto em uma língua e colocá-lo em outra. Envolve programação também, correto ? Pode nos dizer como efetivamente os caracteres japoneses são traduzidos para caracteres romanos, dentro do jogo ?
Como já foi dito, envolve muita programação - para um resultado bonito. É possível traduzir só substituindo texto, mas o resultado disso é bastante limitado - e, às vezes, até mesmo feio. No caso do Snatcher, que tem muito texto, acho que a quantidade de programação e de preocupação texto foi similar... ou seja: perdi mais ou menos o mesmo tempo com ambos. Em jogos que têm menos texto, a parcela do tempo gasta com programação é, certamente, muito maior que a gasta com o texto. Sobre os caracteres romanos... Bem, o Snatcher tinha uma página de 16k inteira "gasta" com uma espécie de "Kanji RAM", por software. Como muito espaço era gasto com os desenhos do Kanji (que eram comprimidos), foi lá que eu coloquei não só os caracteres romanos (também comprimidos), mas também grande parte das rotinas extras do jogo. Mas essa não foi uma das dificuldades deste processo. Localizar os Kanjis e as rotinas de tratamento foi fácil. O problema, nesta parte, foi alterá-las. Numa primeira abordagem, eu tentei modificar o processador de textos para interpretar byte a byte, já que não queria gastar 2 bytes de espaço para uma única letra... afinal, se eu gastasse apenas um byte para cada caractere, meu espaço para armazenamento de textos dobraria, automaticamente. Entretanto, isso não funcionou: todos os comandos do jogo são de 2 bytes e o jogo esperava que tudo nos scripts estivesse alinhado de 2 em 2 bytes, e a leitura do texto byte a byte quebrava todo o interpretador do jogo. Num primeiro instante eu me conformei com a idéia de usar dois bytes por caractere, mas isso não durou mais que meia hora. De cara pensei em fazer uma tabela com todas as combinações de dois caracteres e, com isso, resolver a encrenca... mas isso me pareceu estúpido: eu ia gastar o mesmo espaço que o jogo gastava com Kanjis, mas desta vez com informações absolutamente redundantes... Foi então que eu bolei uma rotina que, dados 2 bytes, ela constrói um caractere com duas letras em tempo real, sendo estas letras correspondentes aos 2 bytes enviados para apresentação. Isso me permitia, com uma tabela ASCII pequena, gerar todas as combinações possíveis de 2 caracteres, sem gastar muito espaço com isso. O resultado é aquele presente na versão final: as letras são "plotadas" duas a duas na tela. (^=

E quanto tempo levou o processo todo ?
Não sei precisar a duração, mas foi cerca de 1 ano e meio para a versão em português atual. Para a versão em inglês eu tive de voltar para a prancheta, porque o volume de texto é significativamente maior (em inglês não dá pra ocultar sujeitos e coisas do tipo, possíveis no português), e não cabia no espaço que eu havia deixado. Então eu comecei a desenvolver uma outra versão, que me tomou mais uns 6 a 8 meses entre implementação e incorporação to texto em inglês. A versão final é dual: se o texto couber, ela usa 3 discos (como a versão em português); se o texto não couber, ela usa 4 discos (como a versão em inglês).

Qual foi a parte mais difícil do processo ?
A parte que quase me deixou louco foi o processamento dos menus. Eu precisava fazer algumas modificações em alguns menus, deslocar letras de uma opção para outra, inverter opções... e eu não consegui entender completamente o interpretador de menus, que não é executado de forma linear (ele é uma das muitas máquinas de estado do jogo, e 90% da lógica e seqüência do jogo está nos scripts dos menus). Então a minha liberdade de modificação era limitada, e eu tive de fazer *muitas* ginásticas para traduzí-los. Para você ter uma idéia, quase para cada ação do jogo existe uma nova cópia do menu, com alguma alteração. Isso faz com que existam diversas cópias similares do mesmo menu. Mas isso só aumentava o trabalho braçal... a parte complicada tinha a ver com submenus: para saber qual submenu abrir, o jogo contava qual opção tinha sido selecionada e pegava o texto da seleção... e saía procurando qual submenu começava com aquele texto. Depois que eu entendi o mecanismo, ficou menos complicado de mexer... mas antes disso, eu não entendia o porque de uma alteração no texto do menu fazer com que ele deixasse de funcionar. Foi um "parto", mas acabei compreendendo o suficiente para modificá-los, embora tenha ficado até o último instante com a preocupação de que talvez eu chegasse em uma situação que não conseguisse resolver. A complicação foi tão grande, em um dado instante, que eu cheguei a abandonar a tradução. Entretanto, indignado com o trabalho perdido, cerca de um mês depois eu voltei a insistir no assunto e, depois de duas semanas de debugging - de 6 a 8 horas por dia (eu ainda tinha férias! rs) - eu consegui entender o funcionamento dos menus e dar prosseguimento no trabalho.

O que o motivou a traduzir o Snatcher ? Se lembra de quando surgiu a idéia de traduzí-lo ? Pode nos contar como foi este dia ?
Sim, me lembro... mas não a data exata. O Ricardo (RicBit) tinha liberado a primeira versão do Shalom em português, e o Adriano (UZIXman) se aventurava com o Young Sherlock... eu achei o trabalho deles interessante e me animei... e pensei em também fazer uma tradução. Entretanto, na época o meu conhecimento de japonês era -10.7 e eu não tinha a menor competência para traduzir algo assim. Traduzir do inglês para o português não me motivava, embora eu ache um trabalho interessante. Aí, navegando por sites que eu gostava - sempre fui fã de Metal Gear e Snatcher - me deparei com o site do Artemio Urbina (http://www.junkerhq.net), onde encontrei os textos do jogo traduzidos para o inglês. Procurei para ver se alguém já estava traduzindo o jogo e vi que muitas pessoas tinham se proposto e tentado mas que, aparentemente, nenhum dos trabalhos tinha tido continuidade... e isso fazia mais de 1 ou 2 anos, naquela época. Juntaram-se então várias coisas: a vontade de traduzir um jogo, o gosto pela história do Snatcher, o texto (em si) já traduzido para uma língua que eu compreendia (inlgês) e o desafio de "ir onde nenhum outro MSXzeiro jamais foi" (rs). Os primeiros betas foram liberados no #MSX da Afternet.

Ah, e Snatcher com caixa e manual em português seria uma boa pedida para a próxima Jaú agora em novembro.....(é um evento anual de MSX em uma cidade do interior do estado de São Paulo, Brasil, não deixem de visitar). Vamos contar os pedidos ?
É uma proposta desde o início. Talvez o dia que eu terminar as alterações e correções... quem sabe até uma versão com música de CD (nada prometido, nada prometido! rs!). Falando sério, além das correções dos textos que são necessárias antes de uma versão "oficial", ainda estou esperando o trabalho de alguns colegas, na parte de gráficos e na tradução do próprio manual. Só quando isso estiver pronto é que pensarei numa versão "full".

Falando um pouco sobre o trabalho de conversão do Shinobi do ZX Spectrum para o MSX (veja mais em: http://www.caetano.eng.br/shinobi ), vi que você não apenas fez o software funcionar no MSX, mas também este software só rodava em fita cassete e agora pode ser executado de um disk drive ou até mesmo de um disco rígido. A conversão em si deve ter sido muito trabalhosa. Como é que se inicia um trabalho de conversão ? Quais ferramentas é preciso ter ? Que linguagem é preciso conhecer ?
Bem, eu refiz a conversão, mas muitas das idéias usei como base a conversão de MSX original para fita, afinal, não ia reinventar a roda. Então, no caso específico do Shinobi, eu tentei entender o jogo e ver porque ele não funcionava em todos os lugares - o que estava errado - e também o que não funcionava de acordo com o jogo original. Depois dei uma boa estudada na arquitetura do Spectrum e estudei o jogo original no Spectrum. Com base nisso, joguei fora quase todas as rotinas da adaptação original e fiz uma espécie de "BIOS" que emulava as funções que eu precisava do Spectrum e fiz o jogo usar essa "BIOS". Note, porém, que não é uma "BIOS" de verdade, porque ela não é genérica e, especificamente, faz o que precisa ser feito para o Shinobi, inclusive as otimizações de impressão de tela e tudo o mais. Resumindo: o processo começa entendendo o jogo em sua plataforma original, compreendendo também a plataforma original. Conhecendo a plataforma original e a destino e sabendo quais são as necessidades do jogo, desenha-se uma série de rotinas que "emulam" o comportamento do hardware original para o jogo. Depois disso, carrega-se o jogo na memória, junto com as tais rotinas, e alguns "patchs" precisam ser feitos nos jogo, para que ele use essas novas rotinas... e é isso. (^=

Houve algum momento em que o projeto de conversão emperrou ? Quais foram as dificuldades ?
É difícil falar sobre as dificuldades de conversão de uma forma genérica, porque elas são muito específicas jogo a jogo. Em especial, no Shinobi, havia um sério problema de desempenho. De uma forma geral, pelo gargalo que o VDP representa, o jogo ficava muito lento. Além disso, o jogo tinha sido feito pensando no Spectrum, que tem a VRAM numa região da RAM e que é diferente do MSX (é na região 4000h a 6000h da RAM, mais ou menos) e tem ROM na região 0000h a 4000h. Além disso, o Shinobi usa uma área da RAM como framebuffer (de E000h a FFFFh, mais ou menos)... o que significa que o jogo desenhava a tela, antes de imprimí-la, a partir do endereço E000h, ocupando até FFFFh... o que no MSX é um problema: FFFFh é um endereço que controla os subslots. Quando o jogo escrevia aí, o MSX travava. Além disso, o jogo não fazia "clipping" dos shapes. Isso quer dizer que se um personagem fosse plotado na parte de baixo da tela, de forma que só a metade de cima do personagem aparecesse, ele ia plotar esse personagem inteiro... e a parte de baixo dele ia aparecer, na RAM, além do FFFFh... isso quer dizer: na região de 0000h a 4000h. Ora, no Spectrum não havia problema: tinha ROM lá. Tudo que era escrito lá, era ignorado pela ROM. Simples assim. Entretanto, no MSX eu não tenho a ROM e, no lugar dela estão as minhas rotinas de adaptação... em RAM. Quando o jogo plotava um personagem alí, detonava com o meu código, e o jogo travava misteriosamente. Creio que estas foram as maiores dificuldades... embora o fato de o jogo sobrescrever toda a região de variáveis do DOS também fosse problemática, algo que eu também tive de contornar e, neste caso, usei o know-how adquirido com o Snatcher, onde algo similar precisou ser feito.

Como é feito o teste de conversão e a depuração ?
O teste e depuração pode ser simples, mas dependendo dos problemas que surgem, pode se tornar complexo. Em geral o teste é feito com um jogo modificado, para ter imunidade, por exemplo, onde não se mata nenhum inimigo desnecessário, para testar o limite do jogo, com todos os personagens na tela, etc e tal. Com isso tenta-se ir até o fim do jogo... E, se ocorrer algum problema, tenta-se encontrar a situação precisa em que ele ocorre (ou seja: tornar o erro reprodutível) quando então é feita uma análise lógica para concluir onde pode estar o problema. No caso do Shinobi, o Adriano (UZIXman) me ajudou bastante, com uma versão modificada do fMSX que ele usa, que imprime num arquivo toda a seqüência de instruções executadas e o estado dos registradores. Com isso foi possível encontrar problemas que, de outra forma, não estava sendo possível depurar.

Que dicas você daria para alguém que queira converter um software do ZX Spectrum para o MSX ?
Que estudem muito ambos os sistemas, o software e percam tempo planejando a adaptação, para evitar retrabalho... e também que estudem alguns jogos já adaptados, para aprender alguns truques úteis na hora de adaptar. Mas, acima de tudo, sugiro que tenham muita paciência. (^=

E quanto a parte de execução em disco e HD ? Existiam travas no código que impediam de ser executado em outros dispositivos ?
O problema é que o jogo destrói toda a área do DOS com o seu framebuffer. Essa é uma característica que veio já do Spectrum, não foi sacanagem de quem adaptou. Entretanto, como ele havia sido adaptado pra acesso direto por portas, acessando direto os setores do disco, tanto fazia ter a área do DOS intacta ou não. Entretanto, se queremos uma adaptação compatível e que rode em todos os lugares, este não é o caminho: o caminho é usar o DOS. Mas como usar o DOS se a área dele é destruída pelo jogo? Simples: guarde uma versão "boa" das variáveis de sistema *antes* do jogo destruí-las. Quando precisar delas, guarde os dados do jogo, restaure as variáveis do DOS, use o DOS e depois restaure as variáveis do jogo. Gambiarra? Bem, acostume-se a isso: adaptar jogo é, sim, gambiarra. E, em muitos casos, você não tem como fugir... a menos que reescreva o jogo todo, do zero. O que define uma boa adaptação é a sua capacidade de fazer as gambiarras certas e da forma mais eficiente (rs).

O MSX tem um hardware parecido com o Spectrum, essas semelhanças quando vai se fazer um trabalho de tradução facilitam o trabalho ou não ?
Eu não diria que "facilitam", mas sim que "possibilitam". Por exemplo: converter um jogo de PC pra MSX é insano, mesmo que seja de 8088. É praticamente reescrever, não se aproveita nada, além da lógica das instruções e, *talvez* alguns dados do jogo. No caso do Spectrum, é possível aproveitar praticamente todos os dados e grande parte do código. Entretanto, a parte de interrupções, vídeo, áudio, controles, etc... precisa ser toda refeita. O mesmo, se não me engano, vale para jogos de SG-1000, adaptados para MSX pelo José Gama (SLotman) e Ricardo Bittencourt (RicBit).

O seu mais recente projeto, Knightmare Gold (http://www.caetano.eng.br/msxpage/kmg), há pouco tempo divulgado, traz a comunidade algo que acreditamos que muitos queriam ter visto já há um bom tempo. A Konami mesmo fez este tipo de trabalho com o King´s Valley II na época lançando duas versões. Knightmare foi um sucesso incontestável, clássico do MSX que merecia o mesmo tratamento. Você está nos proporcionando esta versão. Quando surgiu a idéia ?
A idéia veio do José Gama (SLotman). Ele já vinha falando há algum tempo da história de "colorir o viking" do Knightmare, e várias vezes já tinham comentado sobre "transformar jogos de MSX de Screen 2 para Screen 4". Ele começou tentando e eu dando sugestões de codificação. Mas, num dado momento, ele cansou... e então eu resolvi tentar... e o que começou com "colorir o viking" tomou proporções um tanto quanto maiores, na medida em que percebíamos que mais alterações eram possíveis. As idéias de melhoria visual foram surgindo e sendo implementadas. E foi assim que tudo chegou ao estado em que está hoje. (^=

Vi, através de seu site que este projeto além de gráficos com todo o potencial do MSX2, tem também outras características que tornam a experiência de Knightmare ainda mais divertida. Pode nos dizer quais são estas novidades que Knigtmare Gold irá ter ?
Bem, além de sprites multicoloridos (incluindo personagem, armas, inimigos, etc), foram criadas palhetas específicas para cada fase, os sprites do jogo não ficam mais piscando feito doidos e, agora já implementado com sucesso, o scroll suave. Fora isso, o placar do jogo foi modificado e agora contém mais informações sobre o jogo, a apresentação do jogo foi totalmente refeita, em screen 5 e o jogo tem a opção de músicas de CD, se tudo correr bem, com a possibilidade de novas músicas também. Não lembro se tem mais alguma coisa... q^= Ah, sim, cada uma destas opções pode ser habilitada ou desabilitada, individualmente, proporcionando um controle sobre "como você quer o seu jogo". (^=

Você vem trabalhando no projeto há quanto tempo ?
Desde dezembro de 2004. Quase um ano.

E pode contar como foi e está sendo esta experiência ?
Diferente tanto de traduzir o Snatcher quanto de adaptar o Shinobi. Acho que nunca na minha vida eu tive que reescrever tanto código quanto no Knightmare Gold. A maioria das modificações do jogo eu tive de reescrever de 3 ou 4 jeitos diferentes, até que elas funcionassem a contento ou sem trazer nenhum tipo de efeito colateral. Uma outra novidade é o esquema de trabalhar com "patch" do jogo original. Dá uma certa dor de cabeça, em compensação facilita um pouco a vida em outras situações. Uma novidade final é trabalhar com uma porção de coisas comprimidas bem como uma VRAM lotada de informações, para conseguir que todas as informações necessárias coubessem em 64KB de RAM, sem precisar de nenhum tipo de expansão.

O código da Konami, pode nos contar como eles fazem aquelas 'mágicas' com os sprites, com os elementos do jogo, enfim, como eles conseguem aquela qualidade nos seus jogos ?
Ao contrário do que muita gente pensa, o código da Konami não é mágico, é só inteligente (rs). Em alguns casos ele é bem confuso, embora raramente ineficiente. Se tem uma rotina complicada de entender, então é porque aquele é o jeito mais adequado (ao jogo) dele ser feito. A mágica dos sprites, em especial, é feita com um truque usado por várias empresas, mas a rotina da Konami é mais eficiente. Quando as pessoas "normais" programam, se elas colocam um inimigo no sprite 7, elas não o tiram mais de lá. Só que, no MSX1, se tivermos 5 sprites na mesma linha, o 5o. some. E qual 5o.? O 5o. da esquerda pra direita? Não! O 5o. em prioridade! Assim, se tivermos os sprites 1, 3, 4, 5 na mesma linha que aquele sprite 7 e, por alguma razão, eles permanecerem alinhados, o sprite 7 simplesmente não vai aparecer. O que a Konami faz para contornar este problema? Simples: os inimigos não ficam em sprites fixos. A Konami faz uma tabela em RAM em que a posição 1, por exemplo, vai ser sempre de um mesmo inimigo, desde quando ele aparece até quando ele morre (ou some da tela). Entretanto, na hora de colocar os dados deste inimigo na tabela de sprites da VRAM, a cada duas interrupções (ou seja, 30x por segundo) ela coloca estes dados num sprite de número diferente, desde o 8 até o 31. Do 8 ao 31? E do 0 ao 7? Do 0 ao 7 ela coloca os sprites do personagem principal, que nunca saem de lá... e é por isso que o sprite do seu personagem nunca some ou pisca: os sprites dele são sempre os de maior prioridade. Falando sobre a "otimização" do código da Konami, me lembrei de uma coisa curiosa: no Snatcher teve uma situação em que eu precisava de mais 2 bytes no código principal e, para isso, precisava otimizar rotinas da própria Konami para liberar o espaço. Isso foi feito tirando a generalidade de uma função, que passou a funcionar apenas para uma determinada faixa de valores. Por sorte... o jogo só a utiliza com aquela faixa de valores válida. (^= Antes que alguém pergunte porque fui tão radical em mexer numa função da Konami a ponto de tirar sua generalidade, simples: esse foi um momento em que... ou eu fazia isso, ou não tinha tradução. Depois de pensar muito no assunto e não encontrar outra forma de fazer a modificação, eu analisei o código e vi que aparentemente não era necessário que o código fosse tão genérico... apostei que mudá-lo não traria problemas e, para sorte de todos, de fato não trouxe. (^= Isso mostra o como pode ser complicado - e arriscado - tentar otimizar um código da Konami. (^=

Deve haver algumas falhas no código deles também, isto é verdade ?
Sim, é. É notório o caso do Episode II, que chama uma função de setar a palheta de MSX2 sem verificar se está realmente em um MSX2, fazendo com que o jogo não funcione em HotBits. Vários jogos, como atestado pelo Fábio (FRS), possuem problema de timing que, quando rodados em micros com turbo, ficam muito rápidos. Mas nunca encontrei falhas maiores que estas.

Knightmare Gold precisa de qual hardware para ser executado ?
MSX1 com 64KB de RAM. Mas quase nada fica "habilitável" num micro desses (rs). Para proveito completo do Knightmare Gold, é necessário um MSX2 com 7Mhz, DOS2, IDE+CDROM e 128KB de RAM; ainda não é necessário, mas pode ser útil na versão final ter 128KB de VRAM (de qualquer forma, para o jogo em si vai precisar só de 64KB de VRAM). Mas é possível rodar o jogo com diferentes configurações, variando os recursos que podem ser ligados ou não.

Manual e caixa para Knightmare Gold estão nos planos ?
Sim. Como anunciei na lista, Knightmare Gold deve sair em versão "full".

Muitas pessoas estão ansiosas para ver o novo Knightmare Gold, poderemos ver algo em Jaú / 2005 (evento anual e nacional de MSX, que ocorre na cidade de mesmo nome, estado de São Paulo, no Brasil) ?
Sim, o lançamento oficial será em Jaú 2005. Estou estudando enviar para quem adquirí-lo nesta mesma época (de Jaú 2005). Depois disso, outros usuários só terão acesso ao jogo quando ele for disponibilizado publicamente no site, sem CD... mas também não faço idéia de quando isso ocorrerá.

E, para quem nunca foi, como é estar presente em um evento de MSX ?
Em poucas palavras: é rox! (^= Pra mim, ir aos encontros de MSX não é só ficar por dentro do que rola no mundo MSX... é re-encontrar muitos amigos, algo de que eu não abro mão. Infelizmente tenho tido problemas financeiros e não tem sido possível ir a todos os encontros; mas pelo menos em um por ano eu vou! (^=

Há mais algum projeto em que esteja trabalhando no momento, além do Knightmare Gold ? Poderia nos contar a respeito ?
Sim, há vários... um deles foi sumariamente paralizado quando eu comecei o Knightmare Gold, e é uma outra conversão para MSX2, mas não é de um jogo famoso da Konami, e sim de um jogo que eu sempre gostei (e que, creio, foi uma das melhores adaptações de Spectrum pra MSX). Há outros projetos menores e um certo sonho de adaptar um jogo de PC pra MSX, mas isso ainda tá muito lá adiante. Vamos com uma coisa de cada vez.

E há algum projeto, que mesmo não estando nos planos no momento, você gostaria de realizar futuramente ?
Sim, essa adaptação de jogo de PC pra MSX. É um desafio meio sem precedentes no qual eu tenho o desejo de aprofundar meus conhecimentos de assembly do x86. Claro, será um jogo de 8088, nada muito avançado. Sou louco, mas nem tanto (rs).

Daniel, gostaria de lhe agradecer por esta entrevista, pela paciência e por ajudar o MSX com o seu ótimo trabalho. Espero que continue assim, que tenha sucesso e esteja sempre presente. Muito obrigado e sucesso !
Eu é que agradeço a oportunidade, muito obrigado e gostaria de lhe parabenizar por seu site, além de lhe desejar muito sucesso!

Para quem quiser conhecer de perto os softwares do Daniel, basta visitar seu portal na Internet: http://www.caetano.eng.br , o projeto Knightmare Gold também pode ser visualizado em: http://www.caetano.eng.br/msxpage/kmg.