Tag: BBS

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!

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.

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