As brincadeiras com I/O giraram ao redor de oito LEDs conectados em uma protoboard e aos pinos de I/O 0-7 de um Seeeduino. Um trimpot atuando como divisor de tensão foi usado na entrada analógica 0 para controlar a velocidade de marcha dos LEDs ou escolher qual LED acender, de acordo com o valor lido pelo conversor analógico-digital.

A implementação do protocolo serial via software, usando técnica de bitbanging, foi feita para interfacear um módulo de display da OSRAM, o SCDQ5541.

No próximo encontro, devemos brincar com registradores de deslocamento ou charlieplexing, para acender uma quantidade maior de LEDs, afim de construir um cubo.

O Juba trouxe (e deixou no LHC) um transceptor de rádio amador, com antena dipolo e caixa acústica. Conseguimos captar, mesmo com uma instalação precária da antena nas grades da janela, sinais de outros países (ou pelo menos em outros idiomas, como Chinês, Russo e Espanhol), e algumas transmissões nacionais também.

Além disso, brincamos com uma USRP, que é basicamente uma interface para receber o sinal analógico do rádio e transmití-lo pela USB para processamento em software pelo GNU Radio. Rodamos alguns dos exemplos do GNU Radio e conseguimos sintonizar rádios FM comerciais e ver o sinal de walkie talkies GMRS (deu pra ver a portadora do sinal e as distorções que acontecem depois da demodulação, mas não conseguimos de fato ouvir a voz).

No próximo encontro, devemos fazer uma instalação melhor da antena e começar a preparar o material para conseguir a licença de estação para a Anatel. O Juba já tem licença de radioamador e eu pretendo conseguir uma também.

The results were unsurprisingly similar to x86: 92% of the tests are passing. Given that libraries differ in version from the ones I have on my development machine, and that the baselines were not readjusted to match the different environment, it is a pretty decent score. Environment discrepancies aside, there were some real failures as far as I can tell — some of them are already fixed and should hit upstream soon.

Also of note: by using a similar approach to obtain the text baselines, more than 5200 pixel test baselines were created. After a couple of bug fixes, results remained with 95% acceptance.

Recently, we’ve been hard at work to implement the much needed testing infrastructure to not only help fix and identify bugs, but also to ensure that fixed things won’t break in the future. This infrastructure is implemented by all major ports, like the Mac port, all the Chromium ports, the GTK and Qt ports, etc, and is comprised of a port-specific part, and a port-independent part.

The independent parts are scripts that gathers the (currently) 20000+ tests and feeds them to the port-specific parts, to compare with outputs generated previously with the same tools.

Since some things depends heavily on how a certain platform behaves — font hinting, for example, is largely dependent on the platform — baselines are provided for each platform, in addition to “generic” baselines for some tests. This is one of the reasons the WebKit repository is so large: the LayoutTests directory weighs about 1.4GB of tests and baselines for all the ports.

The platform-dependent part has been implemented and is in the process of being upstreamed. It is comprised of two tools, basically:

• DumpRenderTree, which, as the name says, dumps a textual representation of all the objects that will be used to render the web page — it performs a little more than that, of course, so that the output is in a known state before dumping the output;
• ImageDiff, which compares two images and, if a significant difference is found, outputs the percentage of pixels that changed and a third image that highlights the regions of change.

With these tools alone, and without any EFL-specific baselines, the port manages to get about 72% of acceptance. Given that most web pages renders perfectly under WebKitEFL, this score can be improved. However, as stated, there are a lot of tests, and manually checking each one would be very impractical and time consuming.

By writing a script that would compare the textual output of our DumpRenderTree with the baselines for other ports — and consider the output of the EFL port correct if within certain thresholds, the acceptance went up to 95%, which is pretty satisfactory.

There are still 5% of tests that are not passing,  either because of an unimplemented feature being tested (in which case, the test is temporarily skipped), or because some more deep debugging is required to improve the score. There are the occasional crashers as well, usually after merges with upstream.

The next step is to set up a bot that will periodically execute these tests and warn for potential breaks or changes of behavior.

Infelizmente, a maioria dos sitemas de 8- e 16-bit (que devem ser mais triviais para emular) já possuem emuladores escritos. Posso aprender bastante lendo o código deles (muitos são open source), mas não é a mesma coisa. Eu acredito na reinvenção da roda para aprender — tenho gostado dos resultados obtidos nos últimos anos com essa prática e quero continuar, portanto.

São várias as coisas que pretendo escrever um dia — e as idéias geralmente ficam dormentes até que uma oportunidade apareça. Outro dia, frequentando o Garoa, foi levantada a hipótese da emulação do Pense Bem. Para quem não sabe ou não lembra, o Pense Bem foi um brinquedo fabricado no Brasil no começo da década de 90, com algumas atividades pré-programadas e um mecanismo engenhoso de expansão baseado em livros de atividades, com perguntas sobre vários assuntos e respostas de múltipla escolha.

Procurando na Internet informações sobre o brinquedo, acabei encontrando um blog post onde o autor dissecava o Pense Bem e mostrava a placa de circuito impresso, dentre outras coisas. Algumas dessas foram comentários do Felipe Sanches, que já tinha tido a idéia de fazer um emulador antes mas tinha esbarrado no mesmo problema que esbarrei: conseguir a ROM original para emular.

O microcontrolador do Pense Bem — um Z8 da Zilog — usa mask ROM. Isso significa que a Tectoy (ou a Video Technologies, não sei bem ao certo) encomendou grandes quantidades para a Zilog, fornecendo o arquivo binário para a programação do microcontrolador. O código é gravado na fábrica — não há EEPROM para ler. A única maneira de obter esta ROM seria dissolvendo o encapsulamento de epoxy com ácido nítrico (ou outro ácido forte) e examinar a pastilha sob as lentes de um bom microscópio. Opção perigosa: ácido altamente corrosivo e fumaça cancerígena. Descartada temporariamente. De volta para a prancheta.

Conversando com o Felipe, ele me passou um patch para um esqueleto de um emulador, baseado no código do MESS, que já tem um emulador de Z8. Infelizmente esse pedaço de código seria inútil sem a ROM para emular, e sem a ROM original, acabamos tendo a idéia de fazer a ROM nós mesmos, em assembly de Z8, e escrever um emulador capaz de executá-la.

Embora eu goste de programar em assembly diretamente, sei que isto é um bocado trabalhoso. Portanto, começamos a desenvolver um protótipo em uma linguagem de alto nível. O Felipe já tinha escrito um simulador de mini-game antes, usando JavaScript e SVG. Ele conhece bastante de SVG, afinal é um dos desenvolvedores do Inkscape. Desmontamos um Pense Bem que comprei no Mercado Livre, aproveitamos para mapear um monte de coisa que seria útil para a ROM (matriz do teclado, display, utilização dos pinos do microcontrolador, etc.), fotografamos o que conseguimos e partimos para o desenvolvimento do protótipo da ROM substituta, em JavaScript e SVG.

Em alguns dias, tínhamos um protótipo funcional. Nem todos os modos estavam implementados, mas já tínhamos som (primeira vez, inclusive, que gerei som em software e entendi o que eu fiz! hooray!), display, e teclado funcionais. Usando o algoritmo de escolha de resposta de livros que o Eduardo Habkost encontrou alguns anos atrás, foi possível também implementar a funcionalidade de livros (que é o que as pessoas mais lembram); infelizmente, a implementação atual não consegue responder corretamente nenhuma pergunta de número maior que 16. Mas já é alguma coisa.

Faltam alguns detalhes para terminar o protótipo, mas já é possível usá-lo como um simulador, disponível aqui. Todo o código fonte está disponível sob a Beerware License (basicamente: faça o que bem entender, contanto que mantenha os créditos; se um dia topar com a gente e achar que o simulador vale alguma coisa, não vamos recusar uma gelada) no Github.

Enfim — ainda falta muito para que isso vire, de fato, um emulador. Não sei ao certo se ainda terei vontade de fazer um emulador de Pense Bem, ou se irei procurar alguma outra coisa não emulada por aí. Só sei que reinventar a roda para reinventar a roda valeu muito a pena.

I’ve decided, then, to write yet another FORTH implementation. FORTH is simple enough that you can bootstrap it quite quickly — however, generating native code wasn’t  an option because the Arduino bootloader forbids messing with the program memory (Arduino uses a ATMega, which uses the Harvard architecture — which separates instructions and data — in contrast with the von Neumann architecture used on common computer hardware, where instructions and data are treated like equal citizens). Without my AVR programmer to change the bootloader, I decided to write a simple virtual machine. This is easy for FORTH, as implementing a stack machine is pretty straightforward, even when you’re writing something to run on a 16MHz RISC microcontroller with 1KiB of RAM.

My earlier FORTH-like language was called FINF, meaning FINF Is Not FORTH. This is because most things that makes FORTH a great language (like the ability to extend the compiler with your program) wasn’t implemented. I decided to go through this route this time, too, as I already had the experience — and then extend it later when I were up to the challenge

Even with these simplifications, memory was an issue. By default, avr-gcc stores all string both on program and data memories (it generates code to copy them from program memory to code memory); this is needed because program data can’t be accessed directly. However, this uses up precious SRAM. Earlier versions of FINF had only about 68 bytes free because of this. So, after a little research, I found the pgmspace.h header file (included with avr-libc and thus available on the Arduino), which lets you easily cast memory and offers some other macros and functions to work with things from program memory. This saved a lot of memory. Also, Arduino’s Serial module reserves 128 bytes of RAM (!) for the serial buffer; changed that to 16bytes. With these plus some other minor changes, I got almost half of the SRAM for the environment to use, and FINF was way more stable and wouldn’t crash after defining more than a dozen of words.

I’ve then implemented a simple interface using ANSI escape sequences to get colored output and basic terminal editing shortcuts (deleting words, clearing the screen, interrupting the current line, etc), which used a bit of memory for line buffers. With these, I’ve increased the virtual machine maximum program size and got about 300bytes free. Which is, beliveve it or not, plenty for some light hacking.

So, after some days of alternating between FINF and playing Fallout: New Vegas (more playing than hacking; vacations, after all), I could write the most amazing LED blinker ever known to man:

Source is available on my Github. Clone it and enjoy — and send me patches

Using ideas found scattered over the web, such as Github’s build indicator light, I’ve cooked my own buildbot monitor using a mail indicator bought from a Chinese store (which is really just a RGB LED with an USB interface). A simple Python script polls the buildbot status page every 15 minutes and changes the LED color to be either green or red, depending on the build status. Click on the photo for a full-sized version.

Why use something like this instead of a notification area icon, you ask? Well, this looks way nicer and displays the status even when my screen is locked and I’m away from my computer.

For those unfamiliar with this kind of stuff: the EWS bot will download every single patch submitted to WebKit’s Bugzilla, apply it with a clean tree, and then build the port. If the patch couldn’t be applied, or the build fails, a red bubble shows up in Bugzilla right beside the patch to warn the submitter that there might be a problem with it — clicking this bubble gives the build-webkit script output to give a clue of what happened.

The Buildbot does roughly the same thing as the EWS, with the exception of only running patches that actually went to the repository. Because of this, it performs incremental builds: there is no need to clean the build directory, so each build cycle is pretty fast: if no files relevant to the EFL port has been touched, a cycle will take about 30s, way faster than the 15minutes of each EWS cycle.

Both bots are being run on CPU time donated by Samsung Electronics. Currently there is only one machine running both bots, but more will be added soon.

Last, but not least: with the help of Buildbot, we know which revision is building or not, so expect weekly snapshots of WebKit EFL.

Without further ado, the source code (and other information) is available on its official web site. Enjoy!