Anteriores:
< Trilha Zero >

< Interrupções V: Os Outros "Recursos" >

Já vimos dois "recursos" que podem conflitar: a linha de interrupção e o trecho de memória identificado pelo endereço inicial ou endereço base, a "caixa postal" para transferir informações entre dispositivos e CPU. Mas os conflitos não estão limitados a estes recursos, já que há ainda duas possibilidades de "trombadas": o canal de DMA e o trecho de memória do código em ROM.

Calma: a coisa é mais fácil do que parece. Primeiro vejamos para que serve o DMA, acrônimo de Direct Memory Access, ou acesso direto à memória. Certos dispositivos lidam com enormes quantidades de dados. Se a transferência para a memória desta grande massa de informações fosse controlada pela CPU, que gerencia o funcionamento de toda a máquina, tudo ficaria muito lento. Para acelerar a transferência, incluiu-se o DMA, um circuito na placa mãe dedicado exclusivamente ao controle deste processo. Quando um destes dispositivos vai transferir dados, avisa à CPU que, ciente disso, passa o controle do processo de transferência ao DMA e vai cuidar de seus afazeres. Quando a transferência se completa, o DMA avisa à CPU e fica esperando nova solicitação. É simples assim.

O DMA dispõe de oito "canais", numerados de zero a sete. Tanto nos XT como nos AT o canal DMA2 é sempre usado pela placa controladora dos drives de disquetes e o DMA5 pela placa dos HD. Além desses, o canal DMA4 é reservado pelo próprio controlador de DMA. Restam cinco canais que podem ser atribuídos aos dispositivos que deles necessitem. Que, aliás, não são muitos: além dos drives, em geral quem os usa são scanners, CD-ROM, placas de rede, de som, controladoras de fitas streamer e controladoras SCSI. Se o dispositivo usa DMA, seu manual certamente elucidará que canais podem ser utilizados e como atribui-los ao dispositivo (em geral ajustando jumpers ou dip-switches na placa controladora).

Já o "trecho de código em ROM" é algo ainda mais simples: é o trecho de memória ocupado pelo código usado pelo sistema para acionar diretamente o dispositivo. Não o confunda com o "I/O base adress", ou endereço base, a famosa "caixa postal" usada para troca de informações. O código em ROM é um programinha gravado em um chip de memória ROM da placa controladora do dispositivo. Como é um programa, usa um "pedaço" da memória. Os problemas surgem quando você espeta nos slots da placa mãe duas controladoras cujos códigos em ROM tentam usar os mesmos endereços. O que, aliás, é muito raro, já que a coisa está razoavelmente padronizada e cada tipo de dispositivo encaixa seu código em um trecho de memória diferente dos demais. Quando há conflito, basta mudar o endereço inicial (também, neste caso, quase sempre por meio de jumpers na placa controladora seguindo as instruções do manual). Como disse, os conflitos são raros, mas podem ocorrer. Os dispositivos mais comuns que usam código em ROM e os endereços em hexadecimal prioritariamente ocupados por eles são: discos rígidos (C800h-CFFFh), placas de vídeo (C000h-C7FFh), controladoras SCSI (D000h-DFFFh) e placas de rede (D000h-DFFFh). Como você deve ter reparado, as placas SCSI e as de rede tendem a compartilhar os mesmos endereços, sinal de desastre iminente. Se um dia for preciso instalar ambas na mesma máquina, não se esqueça de ajustar os jumpers para alterar os endereços usados pelo código em ROM de uma delas.

Finalmente, falemos um pouco das controladoras SCSI. O assunto é vasto e vamos nos limitar ao indispensável para evitar conflitos no uso de recursos. SCSI é o acrônimo de "Small Computer System Interface", ou interface para sistemas de computadores de pequeno porte. Trata-se de um tipo de interface padronizada entre periféricos e CPU na qual uma única placa SCSI pode controlar até sete dispositivos a ela ligados "em cadeia". A coisa parece complicada, mas não é: a ligação em cadeia significa que o primeiro dispositivo está ligado à placa controladora, o segundo liga-se ao primeiro, o terceiro ao segundo a assim por diante. A placa controla todos eles. Por isso foi dito que o padrão SCSI pode ser uma solução quando se pretende adicionar um dispositivo a uma máquina na qual não há mais interrupções disponíveis: a controladora SCSI ocupa uma única interrupção e se encarrega de dirimir os conflitos entre os dispositivos controlados por ela.

O padrão SCSI é capaz de transferir dados muito mais rapidamente que o sistema básico de entrada/saída, o que parece fazer dele a interface ideal. Mas cuidado, que há alguns percalços. Primeiro: a própria placa SCSI usa uma interrupção, um canal de DMA, um endereço base e um trecho de memória para código em ROM, e há que ajustá-los para não conflitar com os demais dispositivos. Segundo: nem todo dispositivo pode ser controlado por uma placa SCSI, mas apenas os que obedecem ao padrão SCSI - que costumam ser bem mais caros (os dispositivos SCSI mais comuns são drives de discos rígidos, flexíveis e CD-ROM, scanners e fitas streamer). E, finalmente nem sempre dois dispositivos SCSI se entendem na mesma placa controladora - se bem que devessem fazê-lo. O que, se o livra do mundo negro dos conflitos de interrupções, pode levá-lo ao mundo não menos tenebroso dos conflitos de "Identidade SCSI", um código identificador atribuído a cada dispositivo SCSI que permite à placa controladora saber com quem está falando e compartilhar recursos entre os diversos dispositivos que controla. E conflitos entre dispositivos SCSI ligados à mesma placa podem ser mais desesperadores que os de interrupções, já que até a ordem em que os dispositivos são encadeados pode influir.

Pronto. É só isso, eu juro. Já estamos prontos para discutir, finalmente, como proceder na prática para resolver conflitos entre dispositivos que pretendem compartilhar recursos. Semana que vem começamos a desvendar o mapa da mina.

B. Piropo