A Scopus Tecnologia era uma "figurinha carimbada". Fundada por três colegas de turma (Edson Fregni, Josef Manasterski e Celso Ikeda) tinha se tornado um símbolo (e um alvo) dos defensores e inimigos da reserva de mercado. Inicialmente desenvolvia e produzia terminais de vídeo (vou falar um pouco sobre o que é isso aí adiante) mas recentemente lançara um microcomputador CP/M (vou falar mais sobre isso). Um dos meus colegas (e amigo) já estagiava lá.
O presidente da Scopus era o Edson Fregni. Além do trabalho na Scopus e da função política de defensor da reserva de mercado ele ainda achava tempo para dar aulas na Poli. Um dia reuni coragem e fui pedir para ele um estágio. Quando disse que meu interesse era em software, ele me disse para conversar com o diretor da área, que também era professor da Poli. Descobri que ele estava dando aula naquele momento e fiquei esperando a aula acabar para ir conversar. Após uma longa conversa sobre software eu tinha obtido não só um estágio, mas também um amigo (e futuro patrão, mas isso é mais para frente).
O que é um terminal de vídeo? De forma bem simplificada (vocês podem ver mais na wikipedia), é um dispositivo de entrada e saída para computadores onde a parte de saída é uma tela. Tipicamente a parte de entrada é um teclado e a conexão ao computador é serial (assíncrona ou assíncrona). Nos mais simples os dados trafegam "nus", os mainframes normalmente tinham protocolos onde os dados são agrupados em pacotes e precisam ser confirmados pelo outro lado (através do chamado ACK).
O primeiro terminal da Scopus era puro hardware, mas logo passaram a usar o microcontrolador 8080, o que convergiu para a linha TVA 1000 (Terminal de Vídeo Alfanumérico) com as seguintes características:
- Microprocessador 8080 rodando a um pouco mais de 3 MHz (a frequência foi escolhida para a geração do vídeo)
- Memória EPROM para o firmware (inicialmente a 2708 de 1Kbyte, depois a 2716 de 2Kbytes)
- Memória Ram dinâmica (inicialmente usando chips de 4Kbits depois chips de 16Kbits)
- Vídeo mapeado na memória, usando DMA (8257) e o controlador de vídeo 8275
- Interface serial feita com a USART 8051
- Teclado com teclas indutivas (um luxo!)
Toda a parte lógica estava em uma única placa imensa, que ficava na diagonal por cima do tubo da tela.
Na época em que entrei a Scopus estava finalizando uma primeira "mudança de geração". Os projetistas originais (que eu chamaria de "geração heroica") foram sendo promovidos para cargos de gerência (ou saíram da empresa). A "nova geração" (principalmente na área de software) era um pouco mais preocupada com alguns aspectos mais formais de qualidade.
 |
| A foto é ruim, mas é a única que achei |
Uma historinha ilustra um pouco esta transição deste período heroico. Originalmente o desenvolvimento do software era feito em algo chamado "Gepeto" (não cheguei a ver isso), que usa uma teletype como terminal (uma teletype é um terminal eletromecânico, lento e barulhento). Os fontes eram salvos em fita perfurada. Só tinham um destes equipamentos e o processo todo de edição e compilação eram lentos e incômodos. Daí que no aperto de correção de bugs muitos engenheiros alteravam alteravam direto o código executável no gravador de EProm. Era a chamada "costura": o código novo era escrito por cima do velho. Se o código novo era menor que o velho, bastava completar com NOPs. Se era maior, o jeito era colocar um JMP para uma área não usada, colocar o novo código lá e depois fazer um JMP para depois do código antigo. Neste processo era comum sobrarem alguns restos de código antigo depois do JMP. Pois bem, algum tempo antes de entrar um dos projetistas recebeu uma caixa de disquetes e um saco de EPROMs com a missão de editar os fontes nos disquetes para que gerassem exatamente o conteúdo das EPROMs (que eram cópias das matrizes usadas pela fábrica). O resultado é que os fontes ficavam com JMPs inesperado, definições de dados aparentemente aleatório no meio do código (resto das instruções sobrepostas) e trechos de códigos em endereços esquisitos.
Quando entrei o grosso do desenvolvimento para os terminais era feito em dois equipamentos de desenvolvimento da Intel (Intellec). Um era totalmente original, o outro só tinha a CPU da Intel com monitor e unidade de disquete adaptados pela Scopus. Aliás, esta era outra característica comum desta época: desenvolvimento próprio de ferramentas, com nível variado de qualidade e acabamento.
O meu estágio foi principalmente desenvolvendo um aplicativo para o MicroScopus (como vou falar em um post futuro), mas acabei colocando um pouco a mão em firmware de terminais ainda como estagiário. É claro que estamos falando na correção de bugs.
O terminal envolvido era o TVA1210, que emulava um terminal da Univac. Era um projeto da era heroica (com as devidas costuras registradas no código fonte). A Univac usava um protocolo complicado, tinha até o ACK do ACK. O desenvolvimento acabou extrapolando a capacidade do hardware em termos de desempenho e (em parte) de memória Ram.
No lado da memória, a previsão era usar 4K, mas isso se mostrou insuficiente. Eu mencionei lá atrás que o chip utilizado era 4Kbits, isto significa 4K posições de 1 bit. Para fazer 4Kbytes são necessários 8 chips. Quando estourou os 4K previstos, o projetista teve a ideia de montar só 1 chip da região seguinte. O resultado é que nesta área só podiam ser colocadas variáveis lógicas (flags).
O problema de processamento era mais sério. O Univac dava um tempo curto para o terminal processar os dados enviados e responder com um ACK. Não dava para o terminal da Scopus receber todos os dados, processar e depois responder. O jeito era ir processando os dados à medida em que eram recebidos. Só que existia o risco dos dados serem corrompidos na comunicação. Para isso existia um CRC no final de cada pacote. Ao final da recepção o terminal precisava conferir este CRC e, em caso de erro, ignorar o pacote e enviar um NAK pedindo a retransmissão. Só que o terminal Scopus estava processando os dados à medida em que chegavam... Daí surgiu que existiam dois conjuntos de flags: os "falsos" e os "verdadeiros" (nomenclatura horrível, mas era isso que estava nos fontes). O firmware ia processando os dados e atualizando a tela e os flags "falsos". No final, se o CRC estava OK os flags "falsos" eram copiados por cima dos flags "verdadeiros". Se o CRC dava errado, a tela era apagada e os flags "verdadeiros" eram copiados por cima dos "falsos", revertendo o processamento.
Eu resolvi alguns bugs simples, mas não teve como solucionar o pior deles: o terminal tinha a opção de comandar uma impressora. Quando vinha um pacote errado o terminal imprimia besteiras e apagar a tela e descartar os flags não fazia sumir a cópia impressa!
Nenhum comentário:
Postar um comentário