Anteriores:
< Trilha Zero >

< EIDE e Fast >
< ATA VI: Enganando a CPU >

Há duas semanas esta coluna perpetrou uma avassaladora bobagem ao afirmar que "os responsáveis pelo desenvolvimento da interface EIDE já haviam se apercebido disso e aproximado os circuitos de controle do drive. Mas a interface EIDE fora desenvolvida ainda nos tempos do XT...". Um erro grosseiro, pelo qual me desculpo. Ato falho: pensava em ESDI, referia-me a ESDI, mas digitava EIDE. Portanto, na coluna de 4 do corrente, substituam aquelas referências a EIDE por ESDI, já nossa velha conhecida, que tudo passará a fazer sentido. Mesmo porque nesta série não chegamos ainda à interface EIDE e qualquer menção a ela seria inteiramente descabida. Isto posto, ao trabalho.

Hoje e nas próximas semanas discutiremos a interface ATA, suas características, seu funcionamento e suas limitações. Depois, afinal, veremos as duas estratégias adotadas pela indústria para enfrentar essas limitações: os padrões de interface EIDE e Fast ATA.

A interface ATA é uma extensão natural do barramento de 16 bits que a IBM desenvolveu para o AT e que mais tarde foi adotado como padrão pela indústria com o nome de barramento ISA (Industry Standard Architecture). A maioria dos circuitos necessários à sua implementação já existia nas placas-mãe dos AT e a interface foi concebida de forma a usar apenas os sinais presentes no barramento ISA, ou seja, nos slots de 16 bits do AT. Por esta razão é tão simples implementá-la no projeto de uma placa-mãe com barramento ISA: além de incluir os conectores na própria placa-mãe e incorporar o suporte ao BIOS gravado em ROM, quase mais nada é necessário (por isso pode-se ligar o cabo dos drives IDE diretamente à maioria das placas-mãe modernas).

A interface ATA foi concebida como uma interface de sistema, ou seja, uma interface em nivel lógico. Isso quer dizer que ela responde diretamente a comandos emitidos pela CPU. O drive em si mesmo é um dispositivo inteligente que contém toda a eletrônica necessária a seu próprio controle. Simplificando: quando é preciso ler ou gravar um setor do disco rígido, a CPU simplesmente emite um comando (mais tarde veremos em detalhes como isso é feito) especificando o setor que deve ser lido ou gravado. O resto é com o controlador embutido no drive: interpretar o comando, localizar o setor e enviar os dados dali para a memória, no caso de leitura, ou vice-versa, no caso de gravação. Note que tudo isso é feito sem que a CPU interfira diretamente nas ações necessárias para mover as cabeças de leitura/gravação para o local onde se encontra o setor e ler ou gravar os dados no meio magnético, já que tudo isto é controlado pelo próprio drive.

A interferência da CPU em todo o processo se resume então a emitir o comando e aguardar sua execução. Por isso pode acontecer (e na maioria das vezes acontece mesmo) que a CPU mande ler, digamos, o setor 30 da trilha 100 da face 2, o drive leia os dados em um setor localizado em uma trilha e face totalmente diferentes e os envie à CPU como se estivessem exatamente no local solicitado por ela. A esse processo de guardar e encontrar dados em setores, trilhas e faces diferentes daqueles que a CPU "pensa" que estão chama-se "tradução" (translation) e é uma das características mais importantes da interface ATA, pois torna a localização real dos dados totalmente transparente para a CPU. Trocando em miudos: o drive "engana" a CPU, escondendo dela o lugar onde os dados realmente estão contidos. Como toda a vez que a CPU solicita dados em um determinado local (informando trilha, setor e face) recebe sempre os mesmos dados (que na verdade estão em outra trilha, setor e face), tudo funciona perfeitamente. Ou seja: a CPU fornece uma determinada localização onde "pensa" que os dados estão e a interface "traduz" isso para a localização onde os dados efetivamente estão. A CPU recebe os dados solicitados e prossegue fagueira em sua faina, sem nem se dar conta que foi enganada quanto à localização. Mas como os dados são realmente aqueles que ela havia solicitado (embora "guardados" em um local diferente), todos vivem felizes para sempre na mais completa harmonia. Moral da história: para a CPU não importa que esteja sendo enganada, desde que não tome conhecimento disso. Aliás, no matrimônio... Ah, deixa pra lá, senão a Cora vai me chamar de cínico de novo.

Essa técnica de tradução é muito mais importante do que parece à primeira vista. Na verdade ela dota o sistema de uma flexibilidade extraordinária na medida que esconde da CPU a real geometria do drive (chama-se "geometria" à distribuição dos setores pelas trilhas e faces de um disco; acostume-se ao termo e a seu significado, pois ele aparecerá freqüentemente daqui para a frente; e acostume-se também à nomenclatura adotada pela interface ATA: cilindros no lugar de trilhas e cabeças no lugar de faces). Veja lá: digamos que você informou ao BIOS de seu micro (entrando com as informações sobre o drive no setup) que seu disco rígido tem oito cabeças (ou faces) e 1 000 cilindros (ou trilhas) com 50 setores cada. Isso perfaz um total de 400 000 setores (o que corresponde a 200 Mb, já que os setores são sempre de 512 bytes). Pois bem: desde que seu disco rígido ATA tenha de fato um total de 400 000 setores, pouco importa qual é sua real geometria interna (ou seja, como eles se distribuem pelos cilindros e cabeças). Quando a CPU solicitar que um certo setor de um certo cilindro e de uma certa cabeça seja acessado, o drive executará o processo de tradução e acessará sempre o mesmo setor. Vantagem? Ora, como a geometria interna do drive pode ser completamente diferente daquela que consta no setup e é "enxergada" pelo BIOS, o drive pode distribuir seus setores pelas trilhas e cilindros da forma que melhor lhe aprouver. Inclusive, por exemplo, mantendo um número de setores diferentes em trilhas diferentes.

Mas por que um drive espalharia suas trilhas de um modo tão estranho? Ora, meu amigo, para aumentar sua capacidade. Como esse recurso esdrúxulo pode aumentar a capacidade do drive? Bem, mesmo sendo evidente você tem uma semana para descobrir.

PS: Há dois sábados atrás dei uma palestra na InfoNET 95 em Ubá, cidade simpática que apesar de seus pouco mais de cem mil habitantes e graças ao Pedro Raimundo, micreiro esperto e entusiasmado, montou um evento de informática que me impressionou pelo porte e variedade dos expositores. Onde encontrei à venda uma impressora à cores e jato de tinta por pouco mais de seiscentos reais. Em Ubá, é bom lembrar, encravada em plena Zona da Mata mineira. Algo impensável há poucos anos. Fica o registro não só para dar os parabéns a Ubá e ao Pedro Raimundo pelo evento, mas sobretudo como tema para reflexão. Como fez bem a esse país libertar-se dos grilhões da reserva de mercado...

B. Piropo