Esse email eu escrevi em resposta a uma pergunta que uma pessoa fez na lista de discussão brasileira de usuários do Inkscape.

O cara perguntou sobre alternativas ao Flash. Algumas pessoas sugeriram usar
SVG com javascript e foram trocados alguns exemplos (eu, obviamente, também defendi o uso de SVG). Outra pessoa disse: "pois é... muito legal, mas SVG ainda não funciona no Internet Explorer então não rola fazer em SVG por que quem usa IE não vai conseguir ver". Então alguém falou sobre o projeto que o Google lançou recentemente chamado SVGWeb e que permite que usuários de IE consigam visualizar conteúdo SVG.

=======

Eu não sei se eu já falei a respeito disso aqui na lista, mas algum tempo atrás eu pesquisei sobre esse tema e descobri algumas coisas importantes.

* Flex é uma tecnologia implementada em software livre, mas as aplicações feitas com flex só são possíveis de ser executadas corretamente em uma máquina virtual Flash proprietária da Adobe.

* O SVGWeb é um software livre renderizador de SVG feito em flex.

Portanto, o SVGWeb tem tanto vantagens quanto desvantagens:

A grande qualidade do SVGWeb é que ele permite que conteúdo SVG seja acessado em praticamente qualquer browser sem a necessidade de instalar absolutamente nada no cliente. Todo mundo que tem um Flash player consegue acessar SVG, desde que o SVGWeb tenha sido habilitado pela pessoa que criou a página SVG.

A grande desvantagem é que hoje em dia não existe Flash player livre que seja capaz de rodar o SVGWeb.

Sendo assim, ao usar o SVGWeb na sua página você pode ter a certeza de que as pessoas que se beneficiarão disso serão aquelas que ainda estão presas a um Flash player proprietário. Em compensação, isso cria uma situação onde você não está mais impossibilitado de utilizar o SVG. Ou
seja, o SVGWeb retira o bloqueio que tínhamos no uso deste padrão aberto em função da não-aderência do Internet Explorer ao formato vetorial da W3C. Veja essa tabela de compatibilidade nativa a SVG nos principais browsers. Mas eu te pergunto: de quê adianta usar um padrão aberto, se ele depende duma máquina virtual Flash proprietária para ser exibido?

Na verdade não depende. É possível configurar o SVGWeb para ser usado apenas quando o browser do usuário não tem suporte nativo a SVG. E isso é uma coisa fantástica!

Bem... acho que isso deixa claro que eu considero sim o uso do SVGWeb benéfico, mas com fortes ressalvas, né? Acho que o SVGWeb não deve ser considerado uma solução definitiva. Mas
sim funcionar como "ponte" para uma web mais aberta em um futuro próximo.

Minha dica é: faça sua página usando SVG e coloque o SVGWeb lá configurado pra só ser usado no IE. O dia que o IE for varrido da face da Terra e todos os browsers tiverem suporte nativo a SVG, será possível simplesmente remover o SVGWeb, sem custos adicionais de desenvolvimento e teremos uma web melhor baseada em mais padrões abertos. Enquanto isso não se realiza, sejamos pelo menos amigáveis ao software livre. Tenha sempre em mente que você pode eventualmente ser o culpado por alguém ser obrigado a abrir mão da liberdade no uso de softwares (ou escolher a liberdade e ser excluído do acesso ao seu conteúdo).

Portanto, a regra de ouro é sempre usar tecnologias que não obriguem as pessoas a instalar software proprietário pra acessar o seu conteúdo. Quando se lida com o público, é necessário tomar decisões responsáveis. Talvez você não se preocupe com o seu uso pessoal de software proprietário. Mas não permita que suas opções pessoais se transformem em imposições sobre outras pessoas (efetivamente deixando elas sem opção).

Felipe "Juca" Sanches

Engenharia Reversa IB-200 (receptor de tv digital usb)

If you need an english translation of this technical report or additional info on my reverse engineering efforts, please email me at felipe.sanches@gmail.com and I will gladly help people working on further developments towards support of this device under GNU/Linux.

Comprei um receptor de tv digital usb OneSeg da IBAYO, modelo IB-200 e comecei a fazer engenharia reversa nele para tentar fazer um driver para Linux. Este post tem o objetivo de documentar minhas tentativas e convidar mais hackers para ajudar nesta tarefa que está dando nós na minha cabeça, mas que ao mesmo tempo está servindo para eu aprender um monte de coisas novas. Se você é um programador curioso, não tenha medo dos nomes feios que vão aparecer neste post. Eu também me assustei da primeira vez que vi isso, semana passada :-)

Só pra constar aqui (e pra facilitar as buscas no google de gente procurando informações sobre esse dispositivo) ele é reconhecido pelo comando lsusb como ID 5a57:4210 Zinwell

Usei um sniffer USB para Windows chamado usbsnoop. Com ele fiz alguns logs de operação do dispositivo no Windows usando o software proprietário que vem no CD de instalação. Em um desses logs eu cheguei a abrir o programa e assistir um pouco de vídeo para ter certeza de que no log constam todos os comandos necessários para inicializar o dispositivo, sintonizar um canal e exibir o vídeo recebido. No Linux, eu utilizei um script em perl chamado usbsnoop2libusb. Esse script lê um log do usbsnoop e gera automaticamente um código fonte em C utilizando a biblioteca libusb. Esse código, quando executado, repete as operações que constam no log. Obviamente fazer um driver não é tão fácil. Mas o código gerado automaticamente é um primeiro passo. É um esqueleto de código em cima do qual podemos trabalhar.

Rodei o programa gerado automaticamente a partir do log que continha vídeo e não funcionou, mas o led azul do dispositivo chegou a acender. Sendo assim, resolvi olhar com mais calma para o conteúdo do log. Conversei com um amigo meu, o Lucas Villa Real (desenvolvedor da distro GoboLinux), que trabalhou comigo no Laboratório de TV Digital na USP. Ele me contou que eu deveria procurar informações que começassem com o byte 0x47 e que tivessem comprimento de 188 ou 204 bytes. Segundo o Lucas, essas são as características dos pacotes que compõem o transport stream da tv digital brasileira (variante do padrão ISDB-T japonês). Fiz isso visualmente e constatei que de fato haviam alguns pacotes de dados sendo enviados do dispositivo para o PC e que tinham essas características (com 188 bytes de comprimento). Fiz um script em python que filtra o log pegando só esses pacotes e salvando eles todos concatenados em um arquivo de saída binário (no log constam esses dados em ascii usando notação hexadecimal). Depois compilei e instalei o DemuxFS, que é um software livre desenvolvido pelo Lucas, que serve para auxiliar no debugging de sistemas de tv digital ISDB, especialmente no SBTVD (sistema brasileiro de tv digital).

O DemuxFS é um filesystem virtual que exibe informações de um stream de tv digital na forma de entradas em um sistema de arquivos. Ele pode ser usado com um backend chamado filesrc ("file source") que lê o transport stream a partir de um arquivo (como o arquivo que eu gerei usando o script python) para ajudar no debugging, ou pode ser usado com um backend que leia o transport stream a partir de um dispositivo de recepção de tv digital (para ser usado na prática). A minha idéia é inicialmente escrever um backend para o demuxfs ler o transport stream a partir do IBAYO IB-200. Mas no momento isso ainda não foi feito.

Usando o DemuxFS eu consegui com sucesso montar no Linux o arquivo de transport stream que foi extraído do log de operação no Windows do IB-200. Isso é um ótimo sinal!
Observei que os pacotes que compõem o transport stream são enviados por meio de transferências isoch (isócronas). Eu nunca tinha ouvido falar disso antes, mas depois de um pouco de estudo, descobri que se trata de um dos modos de transferência disponíveis no protocolo USB. Nesse modo, a banda máxima de transmissão de dados é menor, mas há a garantia de que os dados serão enviados dentro de um determinado limite de tempo. Especialistas, corrijam-se se eu estiver falando besteira.

Observei com atenção o log e inclusive modifiquei um pouco o script usbsnoop2libusb para que o programa gerado automaticamente exibisse na tela não apenas os dados retornados pelas chamadas feitas, mas também os dados que tinha sido retornados pelas respectivas chamadas originais quando executadas no Windows. Dessa forma eu pude não apenas repetir as chamadas que constam no log, mas também comparar as respostas que o dispositivo nos retorna no Linux pra ver se em algum lugar as reações do dispositivo divergem das respostas esperadas (as respostas que ele deu originalmente no Windows). No geral, as respostas foram bem parecidas com as originais. Houveram pouquíssimas respostas diferentes, mas acredito que elas não sejam um problema, pois eram mensagens onde apenas 1 ou 2 bytes eram diferentes da resposta esperada e isso até faz sentido, pois há certas informações que variam entre uma execução e outra, por exemplo o nível de qualidade do sinal de recepção de um determinado canal de tv. A cada execução, é de se esperar que o nível de qualidade seja diferente e, eventualmente esse dado será passado para o PC, o que pode caracterizar uma dessas pequenas divergências observadas.

Em um determinado ponto surgiu uma divergência grande. No ponto onde deveriam começar a ser recebidos pacotes das transferências de dados isócronas contendo o transport stream, absolutamente nada está sendo retornado. Todas as transferências parecem estar dando timeout por algum motivo. É importante dizer aqui que houve ainda um outro problema. O script usbsnoop2libusb estava reclamando que o tamanho de algumas das tranferencias isoch era maior que o limite de 32kbytes. Achei isso muito estranho, pois no log constam transferências isoch de mais que 32kbytes e foi justamente dessas transferências que eu extraí corretamente o transport stream. Portanto, não é um erro no log e de fato no windows foi possível fazer transferências maiores que 32kb. Tentei aumentar esse limite para 64kb e recebi uma mensagem de erro da biblioteca libusb quando tentei executar o código gerado a partir dessa nova versão do script. Procurei na internet pelo código fonte da biblioteca e lá existe uma condição "retorne mensagem de erro caso usuário tente fazer uma transferência maior que 32kb" sem nenhuma explicação do motivo para a limitação.

Pesquisei mais na internet e descobri que existe um projeto chamado libusb-1.0 que concorre com a libusb mais famosa (que tem pacote no ubuntu, por exemplo) que é a libusb-0.1. Apesar de terem o mesmo nome, aparentemente a 1.0 é uma versão reescrita da 0.1 e segundo consta no website do projeto ela tem várias melhorias quanto a performance e a determinados bugs da 0.1. Sendo assim, resolvi experimentar a tal libusb-1.0. Baixei a versão de desenvolvimento, compilei e instalei. Depois portei o script usbsnoop2libusb para gerar código que use a biblioteca 1.0 (as chamadas de função dessa outra biblioteca são obviamente diferentes). Esta nova versão do script está disponível no meu svn do GoogleCode. Rodando a minha versão do script consegui gerar código com transferências isoch maiores que 32kb e a libusb1.0 não tem esta limitação. Entretanto, isso ainda não resolveu o problema do receptor de tv digital. Mas ouso dizer que provavelmente este é um problema que precisaria ser resolvido de qualquer forma antes de conseguir fazer o dispositivo funcionar, então considero isso como mais um passo dado rumo ao suporte do IB-200 no Linux.

No momento, eu estou lutando com mais uma deficiência do script usbsnoop2libusb. Existe uma operação que consta no log e que o script ainda não implementou a respectiva conversão para código C. A operação é um USB_FUNCTION_ABORT_PIPE. Mais uma vez, fiquei naquela situação "WTF!?!?". Googlei um pouco e li a respeito do tal do "abort pipe". No protocolo USB, pipes são abstrações de canais de comunicação entre o host (driver no PC) e um endpoint (dispositivo). Por algum motivo que ainda não é muito claro pra mim, existe a possibilidade do host pedir para um determinado pipe ser abortado, ou reiniciado. Imagino que isso seja feito quando um pipe não vai mais ser usado, ou então quando um pipe será reconfigurado. Mais uma vez, peço o palpite dos especialistas :-)

Enfim... uma dessas chamadas de "abort pipe" acontece bem no finalzinho do log que corresponde ao momento em que fechei o programa no Windows e isso faz todo sentido, pois ao fechar o programa, é de se esperar que o pipe usado para o fluxo de dados seja fechado. Mas a outra ocorrência desse comando acontece um pouco antes do início das transferências isoch problemáticas. Sendo assim, acho que não ter o "abort pipe" alí pode ser uma das razões para as transferências isoch não estarem funcionando pra mim no momento no Linux.

A minha estratégia agora é tentar descobrir como se faz pra implementar suporte a "abort pipe" no script usbsnoop2libusb e ver se isso resolve a zica. O problema é que eu não tenho a menor idéia de como se faz para enviar um comando "abort pipe" usando a libusb. Assim que eu tiver mais avanços eu aviso. Por enquanto, aguardo comentários dos hackers de plantão :-)

If you need an english translation of this technical report or additional info, please email me at felipe.sanches@gmail.com and I will gladly help people working on further developments towards support of this device under GNU/Linux.

Gostaria de dar notícias sobre o andamento do meu projeto de construir uma máquina de verdade com o tema da mesa PARTY Land do jogo Pinball Fantasies (jogo de Amiga, PC, e muitas outras plataformas).

Visão geral de como está o PF (este video já foi postado anteriormente no blog):
http://www.youtube.com/watch?v=91HUGSr1reQ

Nesta semana terminei de montar um DMD para a máquina. Utilizei módulos de LED importados da China. Cada módulo tem 24x16 leds. Como eu precisava de um display de 160x16, comprei 7 módulos, sendo assim, meu DMD tem 168x16. Deixei 4 colunas de LEDs sobrando de cada lado do display.

Eu tinha comprado 2 desses módulos pra testar. Depois que eles chegaram e eu testei e deu tudo certo encomendei os outros 5 módulos. Entretanto, os módulos dessa segunda encomenda estão com a luminosidade bem mais forte que os 2 primeiros. Isso é bem chato, já mandei email pro fabricante reclamando, mas duvido que eles mandem outros 2 displays pra mim por causa disso. Vamos ver no que dá. Por enquanto, coloquei esses 2 displays mais fraquinhos, um de cada lado do DMD, pra pelo menos o problema ficar simétrico e ficar na região do DMD que costuma ter menos coisa acontecendo. A maioria das animações acontecem no meio do DMD.

Vejam nesse vídeo o problema da luminosidade diferente nos módulos:


(eu deixei os módulos dispostos dessa forma levemente curvada só pra eles ficarem de pé. Depois vou fazer um suporte para aparafusá-los direitinho)

Estes módulos são controlados pelo Arduino (um microcontrolador baseado em chip atmega) via interface SPI. O Arduino está conectado a um computador via USB. No computador eu rodo um emulador de MSDOS chamado DosBox.



Modifiquei o código do emulador (software livre) para que a cada quadro da emulação ele faça um dump do topo da memória de vídeo emulada e envie esta informação para o arduíno se comunicando pela porta USB. Eu rodo o jogo Pinball Fantasies nesse emulador e o jogo desenha o seu DMD (virtual) naquela região da memória que o emulador fica mandando pro DMD de verdade.

Assim, eu consigo jogar o Pinball Fantasies no emulador e ter um DMD de verdade mostrando as animações do jogo emulado.

Vocês podem ver isso em ação neste vídeo:


Esse outro é mais velho (de quando eu só tinha 2 módulos de LEDs):


Fotos do projeto em:
http://www.flickr.com/photos/felipesanches

Virei personagem de quadrinhos:



tirinha completa em: Nerdson não vai à escola

Valeu, Karlisson! A Campus Party foi demais!

Um amigo me mandou alguns emails nessa semana e depois de conversarmos um pouco sobre sistemas operacionais ele lançou o seguinte questionamento:

a questão "windows X linux" foi só pra ilustrar.

no longo prazo, acho sistemas operacionais (as we know them) nem
existirão. Manja? Isso me parece uma briga por migalhas.

Digo isso pq acredito q, no futuro, não teremos um windows para rodar
programinhas. Não precisaremos de HD, OS, etc. Estará tudo no ar, tá
ligado? Internet sem fio de banda gigantesca, faremos tudo por aí.

Imagina:
- quem brigava pelo mercado de PAPEL CARBONO há 40 anos atrás
- quem tinha uma mina de sal e achava q estava dominando (depois q a
refrigeração domiciliar ficou acessível à todos, a demanda
praticamente sumiu)

Portanto, o q tenho a dizer talvez seja: existe a possibilidade de vcs
estarem se preocupando com MIGALHA.

Já pensou nessa possibilidade?

E aqui está a minha resposta (achei interessante postar aqui no blog para mais pessoas também refletirem sobre esta questão):

sim, já. É a tendência do "cloud computing".

Sinceramente, acho que grande parte disso é baboseira. Estratégia de marketing mesmo. Uma pequena parte está correta. Por exemplo, o que temos hoje como gmail, flickr, youtube, etc. Existem serviços que realmente funcionam bem quando executados "na nuvem".
Mas abrir mão totalmente de uma plataforma computacional local ainda é inviável. E deve continuar por muito tempo sendo assim pois há tarefas que são ideais para serem executadas localmente mesmo, por exemplo processamento de gráficos 3d. Há ainda impedimentos tecnológicos nesses casos mesmo que esses possam obviamente ser superados por novas tecnologias no futuro.

Além disso, eu tenho muito medo dessa tendência por que ela põe em risco justamente essa plataforma de incentivo à criatividade que é o computador pessoal hoje em dia. O computador pessoal é uma máquina maravilhosa justamente por ser uma máquina genérica que permite que se faça absolutamente qualquer coisa que um programador quiser. É como se fosse um mini-laboratório dentro da casa de cada pessoa. Aquelas pessoas que eventualmente se interessarem por computação têm todo o potencial e recursos ali já disponíveis com absolutamente nenhum custo monetário adicional. O único custo para criar é o próprio custo intelectual de se engajar na atividade criativa. É como se vc tivesse um ateliér de arte embutido em cada moldura de quadro do mundo. Todas as pessoas que têm quadros têm aquele potencial disponível. Algumas pessoas vão querer só apreciar a pintura que já está no quadro (análogo aos usuários que não têm interesse em desenvolver programas de computador), mas outras pessoas podem eventualmente se interessar em fazer suas próprias pinturas e, para estes, não haveria barreira de entrada pois todo o ateliér estaria ali embutido por padrão à espera de um surto de criatividade.

É isso que temos em casa hoje em dia. Máquinas versáteis esperando por pessoas inovadoras que queiram produzir soluções computacionais para os mais diversos problemas. E há evidências de que pessoas de fato fazem isso motivadas pelos mais diversos aspectos e freqüentemente se agrupam para participar em atividades criativas coletivas (o que é hoje, por exemplo, o software livre). O cloud computing transforma o PC genérico em um terminal burro. Joga toda a capacidade de processamento para a "nuvem" e leva embora o "ateliér". Num ambiente 100% cloud computing, o custo de se inovar será mais alto, pois os meios de produção tecnológica estarão majoritariamente nas mãos apenas dos provedores de serviço. Computadores genéricos deixaram de estar presentes nos lares pois sua produção industrial será substituida pela produção em larga escala dos terminais burros. O poder computacional dedicado à criatividade caseira estagnará na geração atual de computadores que gradativamente se extinguirá devido às panes naturais do envelhecimento dos equipamentos.

O quanto isso irá afetar a produção criativa é difícil de se dizer, mas a certeza é de que afetará negativamente, pois as pessoas não terão mais (por padrão) autonomia de criar suas próprias soluções computacionais. Isso eu não quero.

Vídeo mostrando como anda o meu projeto da máquina de pinball:

Hoje parei pra ouvir um pouco de música no Jamendo. Trata-se de um site onde artistas podem hospedar seus álbuns desde que estes estejam licenciados sob alguma das licenças Creative Commons. Algum tempo atrás eu convenci meu amigo Guilherme Padovani, vocalista da banda Motocontínuo, a adotar uma licença CC by-sa nas músicas da banda e depois ajudei a inscrever a banda no site.

Um questionamento que nos fizemos na época foi que se estávamos, por meio da licença, permitindo a criação de obras derivadas, então deveríamos fornecer os meios para tal. Ou seja, deveríamos distribuir não apenas o CD pronto, mas também as faixas de estúdio, o "código fonte" do álbum. Sem isso, ficaria muito difícil fazer alterações nas músicas. A única alternativa que restaria para quem não tivesse acesso às faixas de estudio seria regravar a música em estúdio novamente já que tentar separar os canais seria bastante difícil e provavelmente não ficaria com boa qualidade.

Sendo assim, o Guilherme me passou 7 CDs onde estavam os arquivos de áudio das gravações de estúdio separados em canais para cada um dos instrumentos. Como o conteúdo era pesado, decidimos distribuir por P2P. Criamos arquivos ISO dos CDs e fizemos upload no PirateBay. Entretanto, como não tem muita gente baixando este conteúdo, o torrent provavelmente está sem seeders nesse exato momento. Além disso, tem muita gente que não sabe baixar torrents. A tentativa de usar P2P foi fracassada. Imagino que o ideal seria um sistema que exigísse o mínimo possível de conhecimento técnico de seus usuários. Eu realmente espero que pessoas interessadas em música acessem este conteúdo. Não gostaria de limitar o acesso só por que eventualmente as pessoas não sabem lidar com arquivos torrent.

Hoje fiquei pensando bastante sobre esse problema. Enquanto no software livre ocorrem de fato modificações, aprimoramentos, etc. na "música livre", essa prática parece ser quase inexistente (corrijam-me com contra-exemplos caso eu esteja errado). Quais seriam os motivos? Será que as pessoas simplesmente preferem criar música sempre do zero? Concordo que é totalmente subjetivo falar sobre aprimoramentos de uma obra artística. Na área técnica isso é certamente uma questão mais objetiva do que na música, por exemplo.

Derivação incremental propriamente dita - modificações em detalhes como substituir uma linha de baixo deixando todo o resto intacto - eu acho que não teria muito valor. Talvez o maior valor da música livre esteja no acervo de recursos disponíveis para remixagem. Sendo assim, artistas criariam suas próprias obras originais com gravações de novas faixas em estúdio e as complementariam com samples retirados de outras obras livres disponíveis na rede. Ainda assim, para que isso seja produtivo continua sendo necessário publicar as faixas de estúdio na rede para enriquecer este acervo comum.

Vejo muita gente falando a favor do uso de licenças livres, mas não vejo muitas pessoas com as mesmas preocupações que estou expondo neste post. Também ainda não vejo surgirem soluções tecnológicas para viabilizar essas idéias. Seria interessante (e útil) algo como uma SourceForge para música. Ou talvez algo como o Open Clipart Library. Como relatado anteriormente, minhas tentativas de por isso em prática junto com a banda Motocontínuo não tiveram sucesso. Tentei até entrar em contato com o pessoal do Jamendo propondo que o serviço deles contasse com uma área para upload das faixas de estúdio, mas eles também não providenciaram ainda uma solução para o problema já que aparentemente não há demanda suficiente.

Na minha concepção, um sistema ideal além de fornecer para download as faixas de estúdio de um determinado álbum, também deveria ser capaz de indexar este conteúdo e permitir que os visitantes visualizassem o acervo de áudio classificado por tipos de instrumento, estilo musical, etc. Obviamente essa classificação poderia ser feita pelos próprios artistas no momento em que fazem o upload. Entretanto, aposto todas as minhas fichas que muito pouca gente se daria o trabalho de inserir estes metadados. Portanto, seria necessário criar tecnologia para inferir esses metadados automaticamente. O que falta pra concretizar essa tecnologia? Muita matemática! A solução não é trivial.

No final das contas, isso parece ser mais uma tarefa para o Google: "A missão do Google é organizar as informações do mundo todo e torná-las acessíveis e úteis em caráter universal."

RicBit talvez?!

Uns 10 anos atrás um minigame meu quebrou e na época eu abri pra ver como era por dentro. Acabei largando ele aberto por que na época eu me frustrei com o "chip bolha". Tudo o que dá pra ver ao abrir um minigame daqueles são os contatos dos botões, o cristal líquido e uma bolha de plastico derretido. Debaixo da bolha fica um chip minúsculo. Aquilo foi muito chato por que não satisfez minha curiosidade.



Recentemente, brincando com o Inkscape e curtindo minha nostalgia, eu e a Bani criamos um minigame virtual feito em SVG e programado em javascript. Se você usa um browser que implementa o padrão SVG (padrão aberto para gráficos vetoriais na web), então você poderá jogar o nosso minigame aqui. Recomendo usar o Firefox. Não funciona no Internet Explorer; ele é um dos únicos browsers hoje em dia que ainda está em 0% de suporte a SVG atrasando a evolução da web.



O jogo é inspirado numa charge famosa do Tux (mascote do kernel Linux) se preparando para bater com um mata-moscas na borboleta do MSN (da Miscrosoft). O jogo segue um formato tradicional de muitos dos jogos antigos de minigame: basicamente vc tem que bater em todas as borboletas conforme elas forem descendo na tela.

Fazer o jogo foi bastante divertido e foi relativamente simples. Desenhamos tudo no Inkscape. Depois selecionamos cada um dos ícones do display de cristal líquido e atribuímos nomes por meio do atributo id (menu de contexto => Propriedades do Objeto). Depois escrevemos o código em javascript usando as funções de manipulação do DOM (Document Object Model) para controlar a visibilidade dos ícones. Assim o software pode fazer os ícones do display acenderem ou apagarem conforme mandar a lógica do jogo.



A única edição manual (em editor de texto) do arquivo SVG foi para adicionar a tag <script xlink:href="minigame.js" /> e o atributo onload="on_load(event);" na tag svg (análoga à tag body do HTML). Com isso, pudemos escrever todo o código javascript em um arquivo .js externo. Todo o resto da edição do SVG foi feita visualmente por meio do Inkscape.

Já hoje, curtindo as férias da faculdade, resolvi voltar a mexer no minigame quebrado. Peguei o cristal líquido do minigame e tirei algumas fotos. Usei uma fonte de tensão pra acender manualmente os ícones do display. Na verdade, os ícones não acendem individualmente. O display é multiplexado e, portanto, as ligações formam uma matriz de ícones. A cada vez que eu aplico tensão em algum dos conectores do display, um certo grupo de ícones se acende. Tirei várias fotos e comecei a vetorizá-las. A idéia é fazer uma versão emulada em SVG+javascript do minigame do Megaman.



Apesar do processo de vetorização ser um pouco cansativo, o maior problema vai ser programar o jogo. Extrair o código do jogo diretamente do minigame não parece ser possível (de se fazer em casa) pois todo o código fica dentro do chip bolha. Portanto vou ter que reprogramar. Além disso, outra dificuldade é eu não lembrar mais como funcionava o jogo. Talvez eu ainda consiga consertar o minigame e assim conseguir jogá-lo, pra relembrar a lógica. Eu acho que o único problema desse minigame é que os fios que são ligados às baterias se quebraram e os que ligam o speaker também. Depois que eu soldar esses fios, é possível que o minigame ainda funcione.

Ahhh...! Outro problema para a emulação são os sons do jogo... mas isso fica pra depois.