Uma revista digital na era do MS-DOS

For an English version of this post, use the “Language” selection in the right sidebar. The entire site will be translated to the chosen language.

Hoje, se você quiser criar uma revista digital com imagens, animações, músicas de fundo e hyperlinks, basta abrir um editor HTML e começar a trabalhar.

Mas e se você precisasse fazer tudo isso em 1997, usando MS-DOS, com alguns megabytes de RAM, sem navegador, sem CSS, sem JavaScript e tendo que controlar praticamente tudo por conta própria?

Pois foi exatamente essa a encrenca em que me meti quando resolvi criar uma edição especial da WarmNews dedicada ao Zakk Wylde! 🙂

Conforme prometido no post anterior, vou contar um pouco dos bastidores técnicos dessa aventura.

Um pouco de contexto

Em 1997, quando criei a “revista”, ainda era muito comum encontrar computadores com processadores 486 e Pentium, especialmente entre os usuários domésticos brasileiros. Máquinas com 4 ou 8 MB de RAM continuavam em uso, embora os computadores mais modernos já tivessem processadores bem mais rápidos e dezenas de megabytes de memória. E, convenhamos, no Brasil nem sempre o que existia de mais moderno lá fora era o que cabia no nosso bolso!

As GPUs como conhecemos hoje ainda não existiam, mas já tínhamos placas de vídeo com diferentes capacidades gráficas, algumas (raras nas terras tupiniquins) com aceleração 2D e até 3D. Quem não lembra das famosas Trident, geralmente trazidas do Paraguai pelo seu muambeiro preferido?!

Ao iniciar a máquina, o DOS carregava o config.sys e o autoexec.bat, e era nesses dois arquivos que você tinha que fazer toda a configuração necessária para conseguir realmente aproveitar a memória disponível, configurar a porta/irq da placa de som (geralmente uma Sound Blaster), página de código, mapa de teclado, etc.

A maioria dos computadores ainda usava o MS-DOS… na verdade, o próprio Windows 95 usava o MS-DOS por baixo dos panos. DOS não tem interface gráfica. Você tinha uma “tela texto” com 25 linhas e 80 colunas para usar (com monitores VGA, dava pra ativar/usar até 50 linhas). Obviamente fazer uma revista usando apenas tela texto deixaria tudo muito chato e limitado.

Na época, eu basicamente programava em Delphi e Clipper (para aplicações comerciais), Assembly (para baixo nível e performance) e Pascal (para todo o resto).

A WarmNews foi feita em Borland Pascal, com um pouco de in-line Assembly, e explorava os recursos gráficos das placas Super VGA através da interface VESA BIOS Extensions (VBE), permitindo criar uma interface totalmente gráfica com uma performance bastante razoável para a época.

Eu não encontrei o código fonte, provavelmente está perdido em algum backup em zip drive ou CD-R, então além da memória, a maior fonte de informação para esse artigo será o próprio readme que acompanhava a revista.

O padrão VESA VGA (mais conhecido como padrão Super VGA ou VBE – VESA BIOS Extensions) foi um conjunto de normas criado no final dos anos 1980 pela VESA (Video Electronics Standards Association) para unificar o funcionamento das placas de vídeo que ultrapassavam as especificações originais da IBM.

Espaço valia ouro!

Hoje pode parecer ridículo, mas na época em que a troca de arquivos se dava através de conexões com modem discado, economizar bytes não era luxo, era necessidade!

Gravei algumas cópias da WarmNews em disquetes de 1.44 MB para serem distribuídas para amigos próximos. Tive o capricho de criar e imprimir etiquetas coloridas para colar neles, usando uma impressora matricial Canon colorida!

Etiqueta impressa em impressora matricial colorida
Conteúdo do disquete com a WarmNews

O arquivo WNEWSZAK.EXE era um self-extract gerado pelo RAR (o pai do WinRar que vocês conhecem hoje). Após descompactá-lo, os seguintes arquivos eram gerados:

DATA.001        Magazine Data File
DATA.002        Magazine Data File
DATA.003        Magazine Data File
DATA.004        Magazine Data File
DATA.005        Magazine Data File
DATA.006        Magazine Data File
DATA.007        Magazine Data File
DATA.008        Magazine Data File
DATA.009        Magazine Data File
DATA.010        Magazine Data File
DATA.011        Magazine Data File
DATA.012        Magazine Data File
DATA.013        Magazine Data File
DATA.014        Magazine Data File
DATA.015        Magazine Data File
DATA.016        Magazine Data File
DATA.017        Magazine Data File
DATA.018        Magazine Data File
README.BAT      BAT file used to read the readme file
WNEWS.CHK       Internal use
WNEWS.CMP       Magazine Data File
WNEWS.CRC       CRC file
GREAT2!.EXE     WarmBoot BBS ad
SCROLL.EXE      Program used to read text files
WNEWS.EXE       Magazine Program
FILES.LST       This file...
MOUSE.PCX       Mouse Pointer
LOGO.TXT        Logo
README.TXT      Readme File
PERRY.XM        Perry Mason Song

Requisitos mínimos

Já no início do readme tínhamos as informações do hardware mínimo necessário para poder executar a revista:

Note o detalhe da caixa de texto “sombreada”. Isso era comum na época, quando você queria destacar alguma informação simulando um “card”. As bordas eram feitas usando caracteres especiais das páginas de código do DOS (aquilo que muita gente chamava de ASCII estendido). Dependendo dos caracteres utilizados e da página de código configurada, o resultado podia aparecer diferente do esperado. Aliás, era comum evitar acentos nos arquivos README.TXT justamente para não correr esse risco!

Som decente (sai pra lá, mid!!!)

Para os sortudos que tivessem uma placa de som, o WarmNews permitia tocar músicas em background enquanto você lia a revista. Para esse feito, usei rotinas criadas por Charles Attard, que tocava diversos formatos de arquivo (669/MOD/MTM/NST/S3M/WAV/XI/XM).

Por que não MP3? Bem… embora o formato já existisse, ainda estava longe de ser popular, especialmente entre os usuários brasileiros. Além disso, reproduzir MP3 consumia um bocado de processamento, algo que não podíamos desperdiçar em computadores mais modestos. O formato começaria a ganhar muito mais popularidade com programas como o Winamp, lançado em abril de 1997.

Na época, muitos jogos utilizavam músicas reproduzidas através dos sintetizadores FM das placas de som, como os famosos chips Yamaha OPL2 e OPL3 presentes nas Sound Blaster. Também existiam músicas no padrão MIDI, cujos arquivos continham basicamente instruções musicais (notas, instrumentos, duração etc.), deixando a geração do som por conta do sintetizador disponível.

O problema é que, dependendo da placa, o resultado podia deixar bastante a desejar. Naquelas Sound Blaster mais simples, algumas músicas pareciam sair de um tecladinho de brinquedo de criança! Os donos de Commodore Amiga se deliciavam tirando sarro dos PCs com som mixuruca!

Felizmente, algumas pessoas criativas encontraram uma forma de driblar as limitações técnicas do hardware disponível na época, e criaram arquivos que traziam embutido samples de instrumentos musicais reais, além da estrutura da música em si (notas, tempo, duração etc).

Provavelmente o padrão mais difundido na época era o MOD. Os players de música (no nosso caso, as rotinas criadas pelo Charles) usavam uma série de algoritmos que atuavam sobre esses samples para “criar” a variação de diferentes notas musicais e depois “mixar” os instrumentos, gerando o áudio final que o usuário ouvia sair pela caixa de som.

Vejamos o que o readme diz sobre isso:

Memória livre, quanto mais, melhor!

Se tem uma coisa que não mudou muito até os dias de hoje é o fato de que memória nunca é demais, e que continua cara!

Mas na era do DOS, não bastava espetar mais pentes de memória no computador. O MS-DOS tradicionalmente trabalhava com apenas 640 KB de memória convencional, e usar a memória adicional exigia alguns malabarismos. Dependendo do programa, era necessário configurar gerenciadores como HIMEM.SYS, EMM386 ou QEMM, que permitiam aproveitar a memória estendida (XMS), a memória expandida (EMS) e até liberar alguns preciosos kilobytes de memória convencional.

Isso era feito através de drivers como EMM386/QEMM386/HIMEM.SYS.

O readme traz uma seção apenas sobre isso:

Com certeza muitos aqui se emocionaram quando viram “OS/2” acima, não? 😀

Obviamente, se você queria aproveitar todo o potencial da WarmNews e ouvir música de fundo enquanto lia a revista, precisava garantir memória suficiente para que o player conseguisse carregar e tocar os arquivos de música. A própria WarmNews trazia uma versão da música Perry Mason, do Ozzy Osbourne, em formato .XM, para ser usada como exemplo.

O player MMP usava as mesmas rotinas que o WarmNews (feitas pelo Charles), então no readme eu copiei algumas informações do MMP com dicas e instruções para rodar a revista com música de fundo:

Para os mais saudosistas (ou masoquistas!), reproduzo abaixo as explicações que acompanhavam o player MMP sobre as diferentes formas de gerenciar memória no DOS.

Sobre a memória, o MMP utiliza 3 modos para evitar a mensagem de “memória insuficiente” (not enough memory) (muito irritante quando você possui 4, 8, 16 ou mais Megabytes de memória no sistema e precisa de apenas algumas centenas de kilobytes). Ele utiliza os tipos de memória DOS, EMS e XMS.

Os modos possíveis são:

Modo: Por que o MMP usa este modo:

  • DOS
    O módulo carregado é pequeno o suficiente para caber na memória convencional. Porém, se um instrumento tiver tamanho superior a 64 KB (caso o módulo carregado seja um 669, MTM ou XM), o MMP utilizará o modo linear DOS/XMS de 32 bits para evitar truncamento. Este é o modo mais rápido.
  • DOS/EMS
    Os instrumentos não cabem na memória DOS, mas os padrões (patterns) cabem (pressupõe-se que sempre seja esse o caso). Os instrumentos são carregados na EMS, mas são truncados em 64 KB (você receberá um aviso), uma vez que arquivos MTM, 669 e XM podem ter instrumentos com 1 MB ou mais no caso dos XMs.
    Para evitar isso, você deve permitir que o MMP entre no modo linear XMS de 32 bits desativando qualquer gerenciador de memória expandida, como EMM386, QEMM386… e ativando o HIMEM.SYS.
    Note que o modo DOS/EMS é lento; portanto, se você tiver menos do que um processador 486DX de 120 MHz, realmente deve fazer isso!
  • DOS/XMS linear de 32 bits
    Assim como no modo DOS/EMS, o tamanho total dos instrumentos é grande demais para caber na memória DOS. Este é o melhor modo (rápido, toda a memória livre fica disponível e os samples não são truncados em 64 KB). Veja acima como ativá-lo.
    Neste modo, o processador realiza endereçamento linear em modo real (unreal mode)! A Tabela de Descritores Globais (GDT) é modificada, e é por isso que ele é totalmente incompatível com outros aplicativos rodando em modo protegido ou modo V86.

O MMP tenta primeiro entrar no modo linear XMS de 32 bits para que possa liberar memória convencional para o shell do DOS. Se este modo não estiver ativado (verifique na janela de configuração do MMP), significa que o processador está em modo protegido (EMM386, QEMM386 ou o prompt do DOS no Windows estão ativos) ou não há memória XMS livre suficiente.

Que complicação, não?! Mas essa era a vida de quem se aventurava na computação na década de 90!

Criando uma interface gráfica do zero (e até um mini-HTML!)

Além do índice, cada seção da revista tinha uma arte de fundo. As artes foram criadas pelo Binho Miranda, usando fotos do Zakk que peguei na internet. São imagens de 640×480 pixels, com 256 cores, gravadas no formato PCX e exibidas usando recursos Super VGA (VESA VBE). Lembre-se: espaço era ouro, então tínhamos que usar só o mínimo necessário que garantisse qualidade suficiente.

O texto das matérias de cada seção era literalmente “desenhado” em cima da imagem de fundo. Como eu queria fazer algo diferente, resolvi não usar a fonte padrão das telas de texto do MS-DOS. Não me lembro mais o nome da fonte, nem o formato do arquivo, mas trouxe um “detalhe” a mais para a revista, mesmo parecendo “tosco” para os dias atuais.

Outro ponto que tive que codificar foi uma espécie de “html primitivo”. Criei tags para mudar a cor do texto, e criei também hyperlinks básicos para que o usuário clicasse e gerasse alguma ação (geralmente abria uma foto relacionada ao texto destacado).

Sendo uma revista “gráfica”, o uso do mouse era imprescindível, tanto para navegar pela revista (botão esquerdo/botão direito) como para clicar nas opções do índice e nos hyperlinks.

Como o MS-DOS não tinha suporte nativo a mouse, era necessário utilizar um driver específico, geralmente acessado através da interrupção 33h. Além disso, implementei a lógica de navegação, a detecção dos cliques nos hyperlinks e o desenho do próprio cursor, que era uma imagem PCX com uma máscara para simular transparência. A cada clique era necessário verificar se o cursor estava em cima de um “hyperlink”, para realizar a ação necessária.

Havia também alguns efeitos que implementei. A mudança de telas usava um scroll suave, manipulando diretamente a VGA para garantir a suavidade do movimento necessária. Os textos eram desenhados também com um efeito.

Fonte especial, mudança de cores, hyperlinks… era uma implementação rústica e básica de um mini-html

Preparando a revista para distribuição

Aqui estou dependendo unicamente da minha memória…

Pelo que me recordo, a estrutura da revista, as matérias, hyperlinks, fonte utilizada, etc eram definidos em um arquivo texto, usando tags e parâmetros especiais. Depois, um executável lia e “compilava” tudo isso em um arquivo binário (WNEWS.CMP), gerando também os checksums, etc.

O executável da revista (wnews.exe) checava os requisitos mínimos de hardware, lia o wnews.cmp e demais arquivos, verificava a integridade deles, procurava músicas (caso o usuário tivesse passado o diretório em linha de comando), inicializava as rotinas do player de música (se fosse o caso) e, aí sim, exibia a revista para o usuário.

Hoje, quase 30 anos depois, é curioso pensar no trabalho necessário para implementar coisas que atualmente são resolvidas com algumas linhas de HTML, CSS e JavaScript.

Ao mesmo tempo, foi justamente esse tipo de desafio que tornou aquela época tão divertida para quem gostava de programação. Havia limitações por todos os lados, e encontrar maneiras de contorná-las era parte da diversão.

Pena que não encontrei mais o código-fonte da WarmNews. Seria interessante revisitar algumas dessas soluções hoje — embora eu suspeite que encontraria também algumas boas gambiarras! 🙂

Enfim, espero que tenham gostado dessa pequena viagem no tempo. Alguns provavelmente sentiram aquela nostalgia gostosa, enquanto outros devem estar se perguntando como conseguíamos programar sem Stack Overflow, GitHub ou ChatGPT.

Pois é… e ainda nos divertíamos! 😉

Share and Enjoy !

ilumilink 2.0

Planeje toda a elétrica da obra antes de quebrar a primeira parede (e agora de graça!)

O Ilumilink é um programa para planejar visualmente onde vão ficar as tomadas, os interruptores e as lâmpadas de um ambiente — e como cada coisa se liga com a outra. A versão 2.0 acaba de ser lançada e traz uma grande novidade: a licença BASIC passou a ser gratuita.

Por que escrevi esse programa

O Ilumilink não nasceu de uma ideia de negócio. Nasceu de uma necessidade minha, quando estava construindo uma casa.

Em obras anteriores já tinha esbarrado no mesmo problema: fazer o eletricista saber exatamente onde eu queria cada interruptor, cada tomada e cada lâmpada — e, principalmente, o que deveria acender o quê — era uma tarefa complicada. Rabiscos no papel, explicação no meio da obra, marcação de giz na parede: nada disso atravessa uma construção inteira sem virar mal-entendido. E esse tipo de mal-entendido geralmente só aparece quando a parede já está fechada!

Pensei em reccorrer a ferramentas profissionais, do tipo CAD, mas não fazia sentido: complexidade demais para aprender e custo demais para justificar algo que, no fundo, era um problema de comunicação — eu precisava mostrar um layout com clareza, não projetar uma usina nuclear 😀

Como não encontrei nada nesse meio-termo, acabei escrevendo. Só que eu achei que ficou tão legal que merecia ser disponibilizado para outras pessoas que estivessem sofrendo do mesmo problema.

Se você é eletricista, arquiteto, designer de interiores ou simplesmente alguém que gosta de “colocar a mão na massa”, vale os cinco minutos de leitura.


O problema: a elétrica é decidida cedo demais e no lugar errado

Todo mundo que já construiu conhece a cena:

O pedreiro pergunta onde vai a tomada da bancada. Você olha para a parede vazia, imagina a cozinha pronta e responde de cabeça. Três meses depois, com a geladeira no lugar, descobre que a tomada ficou atrás dela.

O problema é que as decisões de elétrica são tomadas na fase mais bruta da obra e desfeitas na fase mais cara. Depois que o revestimento subiu, mudar um ponto significa quebrar parede.

E as ferramentas disponíveis não ajudam:

  • Papel e caneta não mostram a lógica das ligações. Você marca um “x” na parede e torce para lembrar depois.
  • Softwares de CAD resolvem, mas exigem curso, licença cara e paciência — e a maioria das obras residenciais não justifica esse esforço.

O Ilumilink nasceu exatamente nesse meio do caminho.

Tela principal com um projeto de exemplo carregado

O que é o Ilumilink

O Ilumilink é um programa para Windows em que você carrega a imagem da planta baixa — pode ser o PDF do arquiteto exportado como imagem JPG, ou até uma foto do desenho — e vai posicionando os componentes por cima dela, arrastando com o mouse.

Não é CAD. Você não desenha paredes, não cota nada, não aprende comandos. Você posiciona e conecta.

Como funciona na prática

  1. Carregue a planta e informe a escala.
  2. Posicione as caixinhas (de interruptores e tomadas) e as lâmpadas nos lugares onde elas realmente vão ficar.
  3. Crie as ligações: clique no interruptor, clique na lâmpada. Pronto, estão ligados.
  4. Simule: clique no interruptor dentro do programa e veja a lâmpada acender e apagar na tela.
  5. Imprima ou exporte o resultado para levar para a obra.

Esse passo 4 parece um detalhe bobo, mas é o que mais convence quem testa. Você descobre que esqueceu o three-way do corredor clicando no interruptor, não com o eletricista já na obra.

Se você prefere ver a coisa em movimento a ler sobre ela, o canal do Ilumilink no YouTube tem uma série de vídeos com o programa em uso. Os mais úteis para começar:

  • Tutorial Rápido (21 min) — o passo a passo completo, do carregamento da planta ao projeto pronto. Se você for assistir só um, assista esse.
  • Escala e medição (4 min) — como calibrar a escala da planta. É o passo que permite medir distâncias direto no software e, a partir da versão 2.0, calcular a estimativa de fiação.
  • Detectar inconsistências no projeto (4 min) — a verificação automática de erros de lógica funcionando.
  • Propriedades dos objetos (7 min) — altura, voltagem, amperagem, tipo de lâmpada: onde se ajusta cada detalhe.
  • Usando a grade de alinhamento (3 min) — para o desenho sair alinhado sem esforço.

⚠️ Os vídeos acima foram gravados na versão anterior, então as novidades da 2.0 que você vai ler a seguir ainda não aparecem neles. O funcionamento básico, porém, é o mesmo.

Clicando em um interruptor acende/apaga a(s) lâmpada(s) ligada(s) à ele

O que ele faz por você

  • Vários tipos de ligação: simples, paralelo (three-way), four way e ligações virtuais.
  • Lista de materiais automática: quantas caixinhas, quantos módulos de tomada e de interruptor você precisa comprar. Sem contar no dedo.
  • Organização por cômodo: cada item pertence a um ambiente, e você enxerga tudo separado por cômodo.
  • Detecção de inconsistências: o programa procura sozinho os erros de lógica — lâmpada sem interruptor, item sem cômodo definido, tomada em altura inadequada, ligações incorretas. Corrija tudo antes de começar a cortar parede.
  • Controle de cada detalhe: posição, altura, voltagem, amperagem, tipo de lâmpada — tudo editável pela janela de propriedades ou pela árvore de itens.
  • Impressão em várias folhas: plantas grandes são fatiadas automaticamente em várias páginas, respeitando o DPI da impressora, para você montar e levar para a obra sem perder legibilidade.
Relatório mostrando algumas inconsistências encontradas no projeto

As novidades da versão 2.0

1. A licença BASIC agora é gratuita

Essa é a grande notícia. Antes, a BASIC era paga; agora é grátis, e basta um cadastro no site com nome e e-mail para receber a chave.

Com a BASIC você trabalha com projetos de até 150 caixinhas e 150 lâmpadas — o que cobre folgadamente uma casa, um apartamento ou uma loja — sem as limitações do modo de avaliação (que trava em 5 caixinhas e 5 lâmpadas). E a renovação também é gratuita: um clique no botão “Renovar grátis” dentro da tela “Sobre”, sem digitar chave de novo.

A licença PRO continua existindo para quem precisa de mais: sem limite de caixinhas e lâmpadas, exportação de relatórios em PDF, Excel, Word, HTML e imagens, e logotipo personalizado nos relatórios — útil para quem entrega o projeto para um cliente.

2. Ligações em ângulo reto, com “pulinho” nos cruzamentos

Até a 1.x, as ligações eram desenhadas como linhas retas ligando um ponto ao outro. Funciona, mas em uma planta cheia vira uma teia de aranha.

Agora existe uma opção na barra superior para escolher o traçado: linhas retas (legado) ou ortogonal — ângulo reto, no estilo de um esquema elétrico de verdade. No modo ortogonal, cada linha nasce no próprio botão do interruptor e sai pela borda mais adequada da caixinha, então fica claro de qual interruptor cada ligação parte, mesmo em caixinhas com vários módulos.

E veio junto o detalhe que faz diferença de verdade: quando uma linha cruza outra, ela passa por cima com um pequeno arco — o “pulinho” dos esquemas elétricos. À primeira vista você sabe que as duas apenas se cruzam, sem conexão entre elas. Em plantas cheias, seguir o caminho de cada ligação ficou muito mais fácil.

Exibindo ligações em linha reta x ortogonais

3. Estimativa de fiação: quantos metros de cabo comprar

Este é o recurso novo mais pedido por quem usa o programa profissionalmente. Acessado no menu Impressão, o Ilumilink calcula a metragem aproximada de cabo do projeto, separada por condutor e pela cor padrão de cada função:

  • Fase — vermelho
  • Neutro — azul-claro
  • Terra — verde/amarelo
  • Retorno — amarelo

O resultado vem dividido em ILUMINAÇÃO e TOMADAS, com subtotais independentes e um total geral por cor — que é exatamente como o cabo é comprado na loja.

O cálculo usa três parâmetros que ficam na tela de Configuração do projeto e que você ajusta conforme o seu jeito de trabalhar: pé-direito, folga por ponta e percentual de desperdício.

Um recurso que anda junto: agora dá para marcar a posição do quadro de distribuição na planta (botão direito na área da planta → “Definir quadro de distribuição aqui”). Com o quadro posicionado, a estimativa passa a incluir também a alimentação das caixas e a fiação das tomadas, assumindo alimentação em cadeia a partir do quadro.

Um aviso honesto, que o próprio relatório traz: isso é uma estimativa, não um orçamento fechado. O programa não tem como saber o trajeto exato que o eletricista vai seguir com os conduítes, e a bitola em mm² continua sendo definição do profissional. O relatório explica as premissas que usou e as limitações do cálculo — leia antes de comprar o material.

Estimativa de metragem de cabos
Tela de configurações do projeto

4. Desfazer e Refazer

Faltava, e agora tem: Ctrl+Z para desfazer e Ctrl+Y para refazer, também disponíveis no menu do botão direito.

E vale para quase tudo: criar, excluir, mover e editar itens, atribuir cômodo, girar caixinha, criar e remover ligações, definir o quadro de distribuição — e até trocar ou remover a imagem da planta. O histórico é reiniciado ao carregar ou fechar um projeto.

5. Navegar na planta ficou natural

Pequenos ajustes que mudam o dia a dia de quem trabalha com plantas grandes:

  • Zoom com Ctrl + roda do mouse agora mantém fixo o ponto que está sob o cursor, em vez de jogar a visualização para outro canto.
  • Arrastar a planta (pan) segurando o botão do meio do mouse — sem precisar das barras de rolagem.
  • Arrastar itens com zoom aplicado mantém a posição exata, sem os pequenos desvios que se acumulavam a cada movimento.
  • Excluir uma caixinha ou lâmpada pede confirmação, evitando exclusões acidentais.

6. E mais de 20 correções

A 2.0 também carrega uma lista longa de correções — várias delas em situações que podiam corromper o arquivo do projeto (nomes duplicados, nomes com ponto-e-vírgula, renumeração automática de caixinhas), além de melhorias na abertura de projetos antigos e na validação da licença. Se você usa o Ilumilink há algum tempo, essa atualização é especialmente recomendada.


Conclusão

Planejar a elétrica antes de executá-la não é luxo de projeto grande — é o que separa uma obra que fica do jeito que você imaginou de uma obra cheia de puxadinhos elétricos e extensões penduradas.

O Ilumilink foi feito para tornar esse planejamento visual, rápido e acessível a quem não é especialista, e a versão 2.0 fecha o ciclo: com a licença BASIC gratuita, o traçado em ângulo reto, a estimativa de fiação e o desfazer/refazer, não sobra muito motivo para continuar rabiscando a elétrica no verso do projeto.

Baixe e teste — é grátis

O Ilumilink roda em Windows 10 ou superior e o download é gratuito.

👉 Baixe o Ilumilink e cadastre-se para receber sua licença BASIC gratuita

📺 Quer ver funcionando antes de instalar? Os tutoriais estão no canal @ilumilink no YouTube — vale se inscrever, porque os vídeos das novidades da 2.0 vão sair por lá.

🌐 E o programa está detalhado em www.ilumilink.com.br.

Se você testar, me conte nos comentários o que achou — principalmente se for eletricista. **Feedback de quem passa o cabo na parede vale mais do que qualquer lista de recursos 🙂 **

Share and Enjoy !

Great2! – código fonte e técnicas utilizadas

Em 1994 eu era o SysOp da WarmBoot BBS e cursava o último ano de Ciência da Computação. Durante muito tempo, os BBS reinaram absolutos conectando pessoas em todo o mundo, antes de serem eliminados da face da terra com a chegada da Internet para o público geral.

Além da troca de mensagens, os BBS serviam também como repositórios de arquivos, em geral sharewares, freewares, imagens, etc. Usuários discavam para o BBS para baixar/subir arquivos, trocar mensagens, etc. Havia uma tradição em que cada BBS adicionava um pequeno arquivo texto aos arquivos compactados (.arj, .zip, .lzh, etc) do acervo, indicando que ele foi baixado daquele determinado BBS, além de informações básicas como: o nome e telefone do BBS, parâmetros para conexão via modem, etc. Enfim, uma propaganda que ajudava a divulgar a existência do BBS para outras pessoas e, com sorte, captar novos usuários pagantes. Esses arquivos precisavam ser minúsculos, afinal, estamos falando de conexões discadas que variavam entre 2.400bps e 56Kbps, dependendo do seu modem e da qualidade da linha telefônica. Pra se ter ideia, um arquivo de 100KB demoraria entre 5 e 8 minutos para ser baixado em uma conexão de 2.400bps, dependendo das condições da linha!

O WarmBoot BBS era referência na distribuição de Demos de multimidia. Eramos distribuidores oficiais da Future Crew e da Twilight Zone. Sempre achei fantástico o que os demogroups faziam usando assembly, em uma época em que o clock da maioria dos PCs não passava de 40Mhz.

Decidi então fazer algo diferente da maioria dos BBS: ao invés de incluir um arquivo texto chato de “propaganda”, criei algo mais divertido e animado – uma “intro” em modo texto, o great2!. Como pode ser visto no vídeo abaixo (gravado em uma janela emulada do DOS), ao ser executado, o great2! fazia a “propaganda do BBS” quicar na tela, enquanto rolava uma música de fundo juntamente com um VU bargraph animado (no vídeo, a rolagem pode não parecer tão suave, afinal, foi gravado em um emulador de DOS que simulava inclusive a taxa de refresh de um monitor CRT).

Lembre-se, o Windows 95 nem mesmo tinha sido lançado e o Windows 3.1 era meramente uma interface gráfica tosca que rodava em cima do MS-DOS. A maioria dos programas ainda eram executados em modo texto (80 colunas x 25 linhas), nada de mouse, janelas etc! Aqueles mais abonados tinham placas de som em seus computadores (SoundBlaster era o suprassumo da época), monitores CRT (Syncmaster 3 era o que tinha de melhor) e placas “Trident” Super VGA com no máximo 1MB de RAM.

A parte mais interessante do great2! era com certeza o efeito da tela quicando. O modo texto, por padrão, tem um número limitado de colunas e linhas para se trabalhar (80 x 25). Normalmente, rolar um texto significava deslocar as linhas para cima ou para baixo, o que obviamente não causava uma rolagem “suave”, já que cada linha tinha 16 pixels de altura, ou seja, cada deslocamento significava mover o texto na tela no mínimo 16 pixels para cima ou para baixo. O “tchã” do great2! era usar recursos de programação gráfica VGA juntamente com o sincronismo do tempo de retrace vertical dos monitores para “pintar a tela” começando no momento certo e no “pixel” certo, causando um efeito de rolagem suave. O sincronismo do retrace era essencial – sem ele é como se partes da imagem parecessem “quebradas”.

Vou deixar a I.A. explicar o conceito, pois creio que ela fará isso de forma mais didática:

O “motor de rolagem” do programa não redesenha a tela: ele desenha o conteúdo uma vez na memória de vídeo VGA em modo texto e depois altera os registradores da [placa gráfica] VGA para mudar a linha inicial de exibição. Como a VGA permite deslocar a imagem por scanlines dentro das células de texto (25 linhas x 16 pixels = 400 scanlines no total), o movimento fica suave, mesmo sem usarmos um modo gráfico.

A sincronização é feita esperando o vertical retrace do monitor CRT, isto é, o breve intervalo entre um quadro e outro em que o feixe de raios catódicos volta ao topo da tela. Ao atualizar os registradores nesse momento, o código evita flicker e tearing, algo equivalente a usar VSync em gráficos modernos.

Em resumo: o efeito funciona como uma “câmera” que se move sobre uma tela já pronta, usando recursos do hardware VGA e sincronizando as mudanças com o refresh do monitor.

Também pedi pra ela fazer uma simulação animada, pra ficar ainda mais fácil de entender o que acontece:

Simulador de Hardware: Scroll Suave VGA (Modo Texto)

Lado Esquerdo: O monitor CRT real. Repare que o texto não se move na memória, a VGA apenas muda onde a tela começa.
Lado Direito: A VRAM (Memória) está fixa. O retângulo vermelho representa os Registradores da VGA mudando a cada ciclo de Retrace.

É claro que o impacto do great2! não ficava apenas no movimento suave, mas também no tamanho minúsculo do executável (5.7Kb) e na música de fundo. Para tocar a música, usei o HSC Player, disponibilizado publicamente por Hannes Seifert, da NEO Productions (uma desenvolvedora de jogos da Austrália). A música também não é de minha autoria! Peguei pronta na internet e confesso que não me lembro quem era o autor. O “anúncio”, ou seja, o texto colorido foi feito usando o The Draw, um editor de telas ANSI amplamente utilizado pelos SysOps para construir as telas de boas vindas e menus dos BBS. Telas ANSI eram a única forma de adicionar texto colorido na interface de um BBS. Lembre-se, tudo era texto/bytes sendo transmitido pela linha telefônica da forma mais crua possível. Usando ANSI conseguiamos adicionar cores aos caracteres. Em conexões lentas, dava pra ver as telas sendo desenhadas caractere por caractere – haja paciência!

Abaixo está o código fonte do great2!, incluindo meus comentários escritos em um inglês vergonhoso e cheio de erros (tinha 19 anos e havia aprendido inglês por conta própria, lendo revistas e livros americanos sobre programação). Muitas vezes recebi mensagens de pessoas que desacreditavam que um executável tão pequeno podia fazer “tanta coisa”.

O código mostra várias técnicas típicas da programação Assembly/DOS que hoje parecem bem “artesanais”, mas eram normais na época: acesso direto à memória de vídeo (B800h) em vez de APIs gráficas, escrita direta em portas de hardware da VGA (03DAh, 03D4h, 03C8h, 03C9h), sincronização manual com o retrace vertical do monitor, rotação de palheta de cores, uso de interrupções BIOS/DOS (int 10h, int 16h, int 21h), controle explícito de registradores, segmentos e pilha, além de CLI/STI para bloquear interrupções durante trechos críticos.

Também chama atenção o uso de rotinas externas para música AdLib, com callback de IRQ para desenhar VUs na tela enquanto a música toca, e a tela inicial armazenada de forma comprimida e descompactada diretamente na memória de vídeo. Para um programador moderno, é curioso porque quase tudo que hoje seria delegado ao sistema operacional, driver gráfico, engine ou biblioteca era feito “na unha”, conversando diretamente com o hardware e sincronizando o tempo visual quase quadro a quadro.

A AdLib era uma placa de som para PCs, famosa no fim dos anos 1980/início dos 1990, que gerava música por síntese FM usando o chip Yamaha OPL2. As Sound Blasters e demais placas de som que vieram depois mantiveram a compatibilidade básica com a AdLib.

As barras do VU, que simulavam um spectrum analyzer, representavam na verdade o nível de sinal de cada instrumento que estava tocando naquele momento, e dava um toque especial e um certo dinamismo na apresentação.

O great2! era compilado com o tasm – o Turbo Assembler, assembler da Borland usado principalmente em DOS para escrever e compilar programas em linguagem Assembly para processadores x86, como o 8086/286/386.

Continue lendo

Share and Enjoy !

30 anos de Delphi

Dia 14/02/2025 o Delphi completa 30 anos de existência! Nessas 3 décadas, passou por altos e baixos em sua trajetória, mas o fato é que ele está mais vivo do que nunca, e continua sendo a melhor ferramenta de programação RAD disponível no mercado!

Para os “velhos” (me incluo nessa) que tiveram a sorte de viver o começo da “era da informática” e experimentar a programação desde sua forma mais crua até as linguagens de alto nível, o Delphi marcou uma revolução na programação para Windows que, arrisco dizer, até hoje não foi superada!

Contextualizando

Comecei a programar com 11 anos de idade, na época, usando um clone do Apple II com 48K de RAM e 1Mhz de CPU. Ele já vinha com o AppleSoft basic nativo e, obviamente, podia-se recorrer ao Assembler do 6502 para algo que exigisse mais performance. Espetando-se uma placa CP/M tornava possível executar o dBase II e criar aplicações acessando bases de dados DBF. Depois, migrei para os clones dos IBM PCs (um AT 286). Nessa época, todos os cursos de computação ensinavam Lotus 123 e dBase III+ e/ou Clipper. Esse era o caminho padrão para praticamente todos os desenvolvedores no Brasil. Perceberam que todos esses softwares rodavam em D.O.S.? Pois é! O Windows 3.1 nem tinha sido lançado!

Foi uma fase no mínimo interessante e única, onde MicroSoft e IBM “brigavam” pelo próximo sistema operacional de sucesso. De um lado o IBM OS/2 (que por sinal, também rodava aplicações do Windows 3.1) e do outro a Microsoft com o Windows! Hoje todos sabemos quem ganhou a briga.

Com o rápido aumento de popularidade do Windows, a demanda por softwares GUI cresceu em um ritmo acelerado. No entanto, as linguagens de programação e IDEs disponíveis na época, além de escassas, eram pouco produtivas. Havia o Microsoft Visual C++, QuickBasic, Visual Basic, além de algumas “bizarrices” no mercado, como o FiveWin (conhecido também por Clipper para o Windows). A própria Borland chegou a lançar um Turbo Pascal para Windows, que gerava aplicações GUI. Nessa época, na maioria das vezes, programar para Windows era basicamente escrever código bruto chamando diretamente as funções da API do Windows.

Felizmente, em 1.995 a tortura acabou!

Delphi 1.0 [1.995]

O Delphi 1.0 foi lançado e chegou oferecendo uma forma de desenvolver aplicações GUI nativas para Windows muito rapidamente e, melhor ainda, de forma visual e usando o velho e bom Pascal como linguagem de programação! Para fechar o pacote com chave de ouro, trouxe também conexão com os principais bancos de dados, além da VCL (Visual Component Library) – uma biblioteca de componentes visuais que facilitava extremamente a vida do desenvolvedor.

Comprei meu Delphi 1 na (falecida) FenaSoft, se não me engano por R$ 50! Me lembro de ter enfrentado fila para comprar!

Não demorou e o Delphi se tornou uma das principais ferramentas de desenvolvimento para Windows no Brasil. As universidades que ofereciam cursos de computação adotaram o Delphi rapidamente, fazendo com que praticamente todos os estudantes daquela época tivessem contato com a IDE, gerando um efeito positivo onde os recém-formados já saíam da faculdade conhecendo o básico, ajudando a suprir uma demanda crescente das milhares de Software Houses que também o adotaram como principal ferramenta de desenvolvimento dos seus softwares.

Com o lançamento do Delphi 1, comecei a migrar meus sistemas do Clipper 5 para o Delphi. A produtividade era absurda! Nessa época, havia muita discussão nos grupos de programadores em relação a qual era o melhor: VB ou Delphi? Posso citar algumas das vantagens:

  • Código mais eficiente/rápido e nativo (sem necessidade do uso de interpretadores/runtimes).
  • Imensa quantidade de componentes visuais – fora a VCL, havia milhares de componentes de terceiros que podiam ser integrados na IDE, para todos os fins e gostos.
  • Melhor suporte à bancos de dados.
  • Object Pascal – linguagem estruturada e orientada a objetos.

Começava a época de ouro do Delphi! Havia uma infinidade de livros no mercado, inclusive em português, além de revistas especializadas (ClubeDelphi, ActiveDelphi, The Club etc), refletindo a forte demanda por informação de qualidade.

Abrindo um parentesis: foi através do Delphi que conheci um tal de InterBase, meu primeiro contato com um banco de dados relacional. Que felicidade! Chega de bases corrompidas e reindexações diárias. E tudo ficou ainda melhor depois de alguns anos, com a chegada do Firebird.

Em 1.996, ou seja, um ano após o lançamento da primeira versão, o Delphi 2 foi lançado, trazendo compilação nativa para 32 bits e possibilidade de desenvolver em 3 camadas para banco de dados, entre outras novidades.

Nogueira, David I e eu, na BorCon 2002

O Delphi era tão forte no Brasil, que a Borland resolveu fazer uma edição local (em português) da sua tradicional conferência: a BorCon! E foi durante uma das BorCons que me encontrei pessoalmente com o Emerson Facunte, iniciando um movimento que culminou com a criação do DUG-BR.

Durante as 3 décadas, o Delphi mudou de mãos algumas vezes, e viveu uma fase complicada (pra dizer o mínimo) nas mãos da Inprise/CodeGear, até finalmente ser comprado pela Embarcadero, que trouxe a ferramenta de volta aos trilhos.

Pedi para as IAs listarem todas as versões do Delphi e seus anos de lançamento, além das principais novidades de cada versão:

Primeiras Versões (Borland):

  • Delphi 1 (1995): A versão inaugural, que revolucionou o mercado com sua interface visual e RAD (Rapid Application Development). Introduziu a linguagem Object Pascal e o framework VCL (Visual Component Library).
  • Delphi 2 (1996): Trouxe suporte para desenvolvimento de aplicações de 32 bits, aprimorando o desempenho e a capacidade dos programas.
  • Delphi 3 (1997): Novos componentes VCL (incluindo Decision Cube e TeeChart), suporte a Active Forms.
  • Delphi 4 (1998): Melhorias na linguagem, IDE (Integrated Development Environment) e VCL, Code Insight, além de suporte para novas tecnologias como COM (Component Object Model).
  • Delphi 5 (1999): Introduziu o suporte para bancos de dados ADO (ActiveX Data Objects) e aprimorou a integração com a Web.
  • Delphi 6 (2001): Trouxe o suporte para desenvolvimento de aplicações Web com IntraWeb e a tecnologia SOAP (Simple Object Access Protocol).
  • Delphi 7 (2002): Uma das versões mais populares, com foco em estabilidade e desempenho, além de melhorias na IDE e na linguagem. Suporte aprimorado a Windows XP (Temas e Estilos).

Transição e Novas Versões (Borland/CodeGear/Embarcadero):

  • Delphi 8 (2003): Versão focada no desenvolvimento para a plataforma .NET, utilizando a linguagem Delphi para criar aplicações gerenciadas.
  • Delphi 2005 (2004): Retorno ao desenvolvimento de aplicações nativas Win32, com melhorias na IDE e na linguagem.
  • Delphi 2006 (2005): Uniu o desenvolvimento para Win32 e .NET em um único ambiente, oferecendo flexibilidade aos desenvolvedores. Incluía Delphi (Win32/.NET), C++Builder e C# em uma única IDE
  • Delphi 2007 (2007): Melhorias na VCL e na IDE, além de suporte para AJAX (Asynchronous JavaScript and XML) para aplicações Web. Focado em Win32.
  • Delphi 2009 (2008): Introduziu recursos como generics e anonymous methods, aprimorando a linguagem e a produtividade.
  • Delphi 2010 (2009): Foco no desenvolvimento para Windows 7 e na criação de aplicações com interfaces mais modernas. Suporte a touch e gestos.
  • Delphi XE (2010): Integração com subversion na IDE, ferramentas de auditoria e métricas de código.
  • Delphi XE2 (2011): Introduziu o FireMonkey, permitindo a criação de aplicações nativas para diversas plataformas. Compilador 64 bits para Windows.
  • Delphi XE3 (2012): Aprimorou o FireMonkey e trouxe novidades para o desenvolvimento de aplicações móveis.
  • Delphi XE4, XE5, XE6, XE7 e XE8 (2013-2015): Continuaram a expandir o suporte multiplataforma e aprimorar a linguagem e a IDE.
  • Delphi 10 Seattle, 10.1 Berlin, 10.2 Tokyo, 10.3 Rio e 10.4 Sydney: Versões que trouxeram melhorias contínuas, suporte para novas tecnologias e foco na produtividade dos desenvolvedores.
  • Delphi 11 Alexandria e 12 Athens (2015…): As versões mais recentes, com foco em desenvolvimento multiplataforma, melhorias na IDE e na linguagem, além de suporte para as últimas tecnologias do mercado.

DUG-BR (Delphi Users Group Brasil)

Lançamento oficial do DUG-BR na Saraiva (Marcos, Akira, Facunte, Marcelo, Cantu e Nogueira)

Em 29 de março de 2.003, na Livraria Saraiva em São Paulo, durante o lançamento do livro “Delphi 7 Internet & Banco de Dados” do Emerson Facunte, o DUG-BR foi finalmente anunciado publicamente.

A ideia de montar o grupo veio do próprio Facunte, reunindo pessoas chave da comunidade Delphi da época. O grupo era composto por:

  • Emerson Facunte (Saraiva)
  • Carlos H. Cantu (site FireBase)
  • Marcelo Nogueira (CTA)
  • Marcos Gomes (site Delphi-BR)
  • Sidnei Akira Egashira (site Delphi-BR)
  • Eduardo Rocha (site EduDelphiPage)
  • Marcelo Ribeiro (site Active Delphi)
  • Celso Paganelli (revista The Club – só no início)
  • Gladstone Matos (revista Clube Delphi – só no início)
Edu, Nogueira, Marcos, Facunte, Cantu, Marcelo, Akira e Daniel

A missão do DUG era clara: levar conhecimento sobre Delphi para todos, através de eventos com diversas palestras, os quais batizamos de DDD (Delphi Developers Day). Além de fazer total sentido “semanticamente falando”, a abreviação DDD já era amplamente conhecida por todos os brasileiros, pois era como chamavamos as ligações telefônicas entre cidades (Discagem Direta à Distância). Durante vários anos, fui o presidente do DUG-BR, cargo passado posteriormente para o Marcelo Nogueira.

O primeiro DDD foi realizado em Piracicaba-SP, na Escola de Engenharia de Piracicaba (EEP), em 4 de outubro de 2.003. Mesmo sendo estreantes como organizadores de eventos, ele de cara já foi um sucesso, com mais de 200 pessoas presentes! Os temas das palestras foram: Rave Report, Stored Procedures no IB e FB, Aplicações para internet no Delphi 7 e Desenvolvimento RAD Para Linux.

Vista parcial do público no 1º DDD

Desde o início, adotamos a premissa de que a inscrição para nossos eventos seria a mais barata possível, cobrando basicamente o suficiente para cobrir os custos com aluguel de equipamentos, translados, coffee-break etc. Em suma, o objetivo era não deixar que o fator financeiro fosse um empecilho para a participação de alguém! A inscrição para o primeiro FDD custava R$ 12,00 (sim, você leu certo: doze reais! inacreditável, não?!).

Ao todo, foram realizados 10 DDDs em diversas cidades, entre elas Piracicaba, Bauru, Sorocaba, São Paulo e Uberlândia, até o grupo se dissolver. No final desse artigo você encontra a reprodução do report original do 1º DDD.

Presente e futuro – o que esperar?

Torço para que o Delphi continue evoluindo sem perder sua essencia RAD e ganhando cada vez mais qualidade, e que a Embarcadero/Idera continue investindo e acreditando em seu potencial, e se esforce para trazê-lo de volta às universidades, de onde jamais deveria ter saído!

Durante os 30 anos que faço uso do Delphi, nunca tive que recorrer a outra ferramenta de programação para desenvolver softwares desktop para Windows, dos mais variados tipos. Ele evoluiu, acompanhou e deu suporte às inovações e padrões de mercado que surgiram durante essas três décadas, sem praticamente perder compatibilidade com o código legado e sem deixar de ser a ferramenta RAD que tanto gostamos! Isso não é pouca coisa!

Share and Enjoy !

Comprando guitarra da China

Esse é um relato do processo de compra de uma guitarra elétrica da China. Espero que ajude outros que queiram fazer a mesma coisa 😉

Meu interesse era por uma réplica da “Number One“, do Stevie Ray Vaughan. Tentei encontrar na internet fornecedores chineses com bom preço e que enviassem pro Brasil. Tentativas de contato com vendedores em portais como DHGate etc. foram todas frustradas, o que já era um mau sinal. Os vendedores que achei no eBay não enviavam para o Brasil. Finalmente, encontrei no AliExpress um vendedor bem comunicativo e que respondeu minhas dúvidas bem rapidamente. Segundo ele, trabalha em uma fábrica de guitarras na cidade de Shandong.

Após negociar um descontinho (como todo bom brasileiro 😀 ), fiz o pedido no AliExpress. Entre fazer o pedido, pagar os impostos e receber a guitarra, se passaram cerca de 40 dias. O envio foi feito via China Post usando o método Colis Postalis, o que acaba sendo quase que uma necessidade para pagar menos impostos (couriers como DHL, Fedex etc cobram taxas de serviço, além dos impostos normais, portanto, não eram uma opção).

Ao chegar no Brasil, a RF taxou o produto usando como base de cálculo o valor arbitrado de USD 80. No fim das contas, o valor total gasto ainda compensou bastante!

As dicas para esse tipo de compra são:

  • Converse antes com o vendedor e tire todas as suas dúvidas. Se ele não responder, já descarte pois é sinal de falta de comprometimento (ou “gópi”).
  • Não compre de lojas que participam do programa Remessa Conforme, do contrário, de cara, já na compra, você irá pagar 94% de impostos (60% taxa de importação + 17% ICMS) sobre o valor total do pedido, deixando o valor final um absurdo!
  • Certifique-se que o método de postagem tem rastreio, para que você possa acompanhar o andamento da entrega. Não use couriers (DHL, Fedex etc) para transporte, do contrário, além dos 94% ainda pagará pelo serviço deles de desembaraço etc. Chega mais rápido? Sim! Mas a facada é bem maior!
  • Fique de olho no valor do frete, pois ele entra também no cálculo do imposto. No meu caso, o frete foi grátis.
  • Tenha em mente que é uma guitarra chinesa, ou seja, não espere a qualidade de uma original.

Segue o link do vendedor, lembrando que ele tem diversos modelos de guitarra (veja alguns no final desse post) 🙂

Sobre a guitarra

Pelo preço pago (mesmo com os impostos), vale muito a pena! A construção é muito boa! Obviamente o hardware usado é “genérico chinês” – por esse preço, não tem milagre – mas confesso que me surpreendi positivamente com o que chegou.

A atenção aos detalhes também foi uma surpresa, como vocês podem conferir nas fotos abaixo. Segundo o vendedor, as madeiras usadas nela são: Alder/Amieiro (corpo), Maple/Bordo (braço) e Rosewood/jacarandá (fingerboard).

O vídeo abaixo foi gravado com tudo”original”, ou seja, sem ter trocado nenhuma peça com exceção das cordas. A única coisa que fiz foi mandar pro Feio Tomaz, luthier aqui de Pira, que deu uma geral ajustando a ação, intonação, regulou alavanca, hidratou o braço, trocou as cordas [coloquei Elixyr 0.9 – bem mais leves do que as que o Stevie usava] etc, ou seja, basicamente aquele trampo básico que se deve fazer em qualquer guitarra recém comprada 😉

Algumas fotos

Abaixo algumas fotos da guitarra recebida.

Outras guitarras

Abaixo algumas outras guitarras desse mesmo vendedor. Tem pra todos os gostos 🙂

Clique nas imagens para mais informações

Share and Enjoy !

Robô aspirador – vale a pena?

Os robôs aspiradores de pó já existem há algum tempo e geralmente são encontrados em diversos modelos, com diferentes funcionalidades. Fato é que eles têm ficado cada vez mais baratos e inteligentes, sendo possível encontrar modelos simples com preços abaixo de R$ 500.

Durante um tempo, duvidei da eficiência desses robôs, mas recentemente decidi arriscar e comprar um pra ver no que dava. Uma coisa era certa: fugiria dos modelos “pé de boi” e escolheria um que tivesse, no mínimo, recursos que considero essenciais para ter um resultado satisfatório, sendo:

  • Retorno automático para a base de carregamento
  • Mapeamento automático da “casa”
  • Possibilidade de definir áreas proibidas ou barreiras virtuais que ele não pode passar
  • Bom custo x benefício

Sendo assim, depois de alguma pesquisa, comprei no AliExpress o Abir X8, uma marca chinesa, mas que tem armazém no Brasil, ou seja, você compra o produto que já está no estoque do país, sabendo exatamente quanto vai pagar (sem risco de taxas etc.) e a entrega, no meu caso, foi feita em 3 dias (pelo Correio). A Abir tem alguns outros modelos com funcionalidades inferiores ou superiores. O X8, na minha opinião, foi o que apresentou o melhor custo x benefício. Além dos recursos essenciais que listei acima, ele também “passa pano” e possui uma luz ultravioleta que vai matando os germes do chão.

Aparentemente o X8 é baseado em uma plataforma OEM usada também por outras marcas. O robô Smart 700, encontrado no mercado nacional, provavelmente usa a mesma plataforma do X8. Optei pelo X8 porque o Smart 700 é um modelo mais defasado da plataforma, sem a luz ultravioleta.

Na prática

Alerta de spoiler: valeu cada centavo!

O X8 possui tecnologia LIDAR, que usa um laser invisível para fazer o mapeamento 3D das áreas e que, para a minha surpresa, funcionou excepcionalmente bem! Você liga o robô e imediatamente ele mapeia todo o espaço que conseguir “enxergar”. Depois, conforme vai se deslocando e tendo acesso a outras áreas da casa, o mapa vai sendo ampliado automaticamente. Não canso de acompanhar, pelo aplicativo, o mapeamento em tempo real!

Mapeando novas áreas enquanto limpa

Por falar em aplicativo, o X8 usa o app Smart Life (disponível para iOS e Android). Através dele você consegue configurar todos os parâmetros, como língua (sim! ele fala em português!), salvar os mapas de diferentes andares da casa, definir as áreas de exclusão e barreiras/paredes virtuais, ligar/pausar remotamente a aspiração, etc. Como o Smart Life se integra com a Alexa e Google, dá pra controlar o robô através dos dispositos Echo da Amazon (ou qualquer outro que possua Alexa) ou do Google Nest.

No fim do primeiro teste, o resultado foi surpreendente! A quantidade de poeira, pequenas folhas de plantas, etc. que ele conseguiu aspirar foi impressionante, assim como a “esperteza” em mapear e traçar os caminhos por onde vai passar, entrando e saindo por debaixo de camas, mesas, cadeiras, etc. sem dificuldade! O único ponto de atenção é tirar do chão qualquer fio ou cabo de energia, pois muito provavelmente vão enroscar no robô, bem como aqueles tapetes pequenos de “limpar os pés” que são muito leves e podem “embolar” quando o robô tenta passar por cima.

Sensores anti-queda em ação
Se entrou, tem que saber sair 🙂

Feita a primeira aspiração, era hora de trocar o depósito de residuos (poeira) pelo de água, para testar o recurso de passar pano (conhecido como MOP). O X8 tem capacidade para cerca de 300ml de água, que pode inclusive estar adicionada de produtos de limpeza (não abrasivos). Aproveitei o momento para definir no mapa as áreas e exclusão, como por exemplo, onde há tapetes. Você pode definir áreas de exclusão tanto para aspiração como para o MOP, de forma independente.

Conclusão

Como já adiantei no spoiler acima: Valeu cada centavo! O X8 cumpre o que promete, com uma eficiência muito acima do que eu esperava. É uma daquelas coisas que depois que você tem, não fica mais sem! 100% aprovado! Aqui está o link de onde comprei o meu.

Lembre-se: prefira comprar de vendedores que tem estoque no Brasil, e preste atenção no anúncio pois na maioria das vezes há códigos de cupons de desconto disponíveis no próprio anúncio 😉
PS: A Abir diz que dá 3 anos de garantia para o produto.

Share and Enjoy !

1 2 3 … 31