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 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
