Bernd Schmidt, autor do UAE, conta como transformou uma ideia pessoal — manter o software do Amiga vivo ao migrar para PCs — em um projeto de emulação que acabou gerando uma família inteira de emuladores.
Motivação e primeiros passos
Schmidt descreve que a motivação inicial foi prática e técnica: ao migrar para PCs queria continuar ouvindo músicas e executando jogos do Amiga, como as trilhas de Turrican. Ele vinha de experiências com computadores anteriores (como o CPC) e já havia escrito um emulador dessas plataformas, o que tornou natural a tentativa com o Amiga quando o hardware de PC ficou mais capaz.
O primeiro boot e o nome “Unusable Amiga Emulator”
Depois de mapear opcodes do 68000 e implementar a emulação da CPU, Schmidt viu o Kickstart começar a rodar em poucos dias. O primeiro resultado visível foi uma imagem de Workbench com uma mão deformada — consequência de bugs na implementação do blitter. O apelido inicial, Unusable Amiga Emulator, surgiu como uma brincadeira ligada a uma referência a códigos de erro do Windows NT e ao acrônimo “AE” (Amiga Emulator).
Principais problemas técnicos: Copper, timings e disco
Para Schmidt, o desafio maior foi a sincronização entre CPU e chips personalizados do Amiga, especialmente o comportamento do Copper. O Copper é um coprocessador que espera por posições específicas na tela e escreve registros de vídeo — a dúvida era exatamente quando essas escritas surtiriam efeito. A solução conceitual que ajudou bastante foi entender que o Copper reside em Agnus e que escrever em registros relacionados a Denise pode implicar um atraso extra.
Outro ponto foi o desempenho: ser fiel ao ciclo por ciclo do 68k e ao acesso às pistas de vídeo era inviável em hardware da época sem aplicar heurísticas que detectassem cenários em que o Copper não atuava, permitindo renderizações mais rápidas.
Emulação de disquetes também trouxe dificuldades por conta de formatos especiais e proteções. Embora a modelagem do controlador em si não fosse complexa, transformar cópias físicas em imagens de disco exigia um Amiga real para leitura, e alguns esquemas (como as “Long Tracks”) complicavam gravação.
Som, portabilidade e código aberto
O chip de som Paula não foi considerado intratável — trata-se de amostras digitais — mas em CPUs como 486 havia risco de interrupções audíveis se o emulador não gerasse áudio rápido o suficiente. Questões avançadas de processamento de sinal e filtragem foram contribuídas por terceiros.
UAE foi pensado com alguma portabilidade em mente: o desenvolvimento em Unix/Linux e o uso de bibliotecas como SVGALib facilitaram rodar o projeto em várias plataformas. Desde cedo Schmidt optou pelo modelo de código aberto; a licença GPL veio mais tarde quando houve interesse em empacotar ROMs licenciadas por terceiros (Cloanto).
Colaboração, limites e evolução
Com a abertura do código, contribuições e forks proliferaram — nem todas alinhadas com a visão original de Schmidt. Ele admite desconforto quando recursos eram adicionados rapidamente, sem a preocupação arquitetural necessária; ainda assim reconhece que a colaboração ampliou o projeto além do que ele faria sozinho.
JITs (compilação just-in-time) e reimplementações posteriores aceleraram muito a emulação, embora Schmidt tenha dito que nunca foi o foco principal para seu uso pessoal (ele era mais interessado em jogos e demos do A500).
Hoje, embora tenha se distanciado do projeto principal e mantenha seu Amiga guardado na prateleira, Schmidt ainda inicializa UAE ocasionalmente para ouvir músicas antigas. Ele segue trabalhando com compiladores e reconhece que muito do sucesso do UAE veio da combinação entre curiosidade técnica e colaboração aberta.
Fonte: Retro Replay