O projeto Base64, de Jörgen Bilander, substitui o processador Motorola 68000 por um núcleo implementado em FPGA e inclui 24 MB de Fast RAM, armazenamento por microSD e suporte a MapROM. Em testes práticos documentados por CRG, a montagem do hardware revelou dois problemas distintos: módulos de SDRAM defeituosos em algumas placas iCESugar-Pro e um bug de gateware relacionado ao comportamento de reset que afetava a enumeração de Autoconfig em resets de software.
O hardware por trás do Base64
O Base64 usa uma placa carrier de quatro camadas que se conecta ao soquete de 64 pinos do 68000 do Amiga. No lugar do chip original vai um módulo Muse Lab iCESugar-Pro v1.3 em um soquete SO‑DIMM de 200 pinos. Esse módulo traz um FPGA Lattice ECP5, 32 MB de SDRAM, 32 MB de SPI flash e interface microSD. A placa carrier faz a adaptação elétrica entre o FPGA e a placa-mãe do Amiga, com conversores de nível (SN74CBTD3861) e circuitos para clock e alimentação.
Observação de segurança: o iCESugar-Pro não isola a alimentação USB 5V da trilha de 5V do Amiga, por isso a documentação do projeto orienta a programar o módulo fora do computador para evitar ligação involuntária de duas fontes.
Como o Base64 executa um 68000 a ~42,5 MHz
O repositório do projeto inclui duas implementações de processador; a versão testada por CRG usa o núcleo fx68k, que tem como objetivo reproduzir não só o conjunto de instruções do 68000 mas também o comportamento de tempo por ciclo (“cycle-accurate”). A placa Rev C gera um clock sincronizado com o sinal de 7 MHz do Amiga e, por meio de um multiplicador ICS570B, obtém um clock efetivo de cerca de 85 MHz no FPGA; o núcleo fx68k opera a aproximadamente seis vezes a frequência original do 68000, resultando em ~42,5 MHz em máquinas PAL.
Importante: operações internas ao FPGA podem rodar nesse clock mais alto, mas acessos aos recursos da placa-mãe do Amiga (como Chip RAM ou periféricos que usam o barramento original) ficam limitados à sincronização do barramento de 7 MHz. Em outras palavras, o ganho depende de quanto trabalho do software acontece dentro do domínio acelerado versus no barramento original.
Memória, Autoconfig e MapROM
O Base64 expõe 24 MB de Fast RAM vindos da SDRAM do módulo. Essa memória é dividida em duas áreas: 8 MB mapeados no espaço Zorro II tradicional ($200000–$9FFFFF) e 16 MB adicionais acessíveis a partir do espaço de endereçamento de 32 bits do processador implementado no FPGA, iniciando em $08000000. Uma ROM de diagnóstico registra essa memória extra no AddMemList do Amiga.
O gateware apresenta três funções Autoconfig: produto 13 para Fast RAM, 14 para a ROM diagnóstica e 11 para o controlador SD. O acesso ao SD usa o driver sfsd.device (versão 2.4 na versão liberada) em vez de simular um controlador IDE convencional. O Base64 também oferece MapROM para rodar uma cópia de Kickstart a partir do acelerador.
Dois problemas durante a montagem
No primeiro teste, CRG obteve uma tela diagnóstica informando memória defeituosa. Ambos os carriers montados exibiam o mesmo sintoma, e um bitstream de teste para o iCESugar-Pro confirmou erros na SDRAM de alguns módulos. Muse Lab reconheceu que certas unidades foram entregues com chips de memória defeituosos; CRG prosseguiu com um módulo substituto emprestado para continuar os testes.
Com memória funcional, o acelerador chegou a inicializar um Amiga 500 Plus e apresentou valores reportados pelo SysInfo — cerca de 43,1 MHz de clock, Dhrystone 3.551 e estimativa de 3,7 MIPS — observações que o próprio CRG tratou como leituras do SysInfo, não como medições independentes.
Bug de reset e a correção fx68k v1.2.2
O problema mais relevante apareceu ao conectar expansões (Diego e Ripple IDE) num A500 Plus: resets de software feitos por LoadModule repetidamente retornavam ao pedido de disco de Kickstart. Um reset de teclado (Ctrl‑Amiga‑Amiga) funcionava normalmente. A diferença técnica é que a instrução RESET no 68000 apenas aciona o sinal externo /RESET sem forçar /HALT; a placa precisava limpar o estado de Autoconfig quando /RESET fosse acionado.
A versão anterior do gateware resetava suas funções internas de Autoconfig somente quando /RESET e /HALT vinham juntos. Em resets de software, as funções internas do Base64 mantinham a configuração anterior, provocando conflitos de alocação de endereços com outras placas. O fx68k v1.2.2 passa a reinicializar as funções de Autoconfig sempre que /RESET é acionado, além de tornar configurável a duração do pulso de reset (padrão: 132 ciclos do clock de ~7 MHz, ≈18,6 μs) e registrar o sinal de distribuição de reset para melhorar o fechamento de tempo do FPGA. O build documentado alcançou um Fmax de 89,103 MHz contra uma restrição de 85,900 MHz sem erros de setup/hold reportados.
Testes em diferentes Amigas e limitações conhecidas
CRG testou o Base64 em quatro configurações: A500 Plus, A500 Rev 3, EATX2000 e uma B2000 modificada. Os resultados variaram: no A500 Rev 3 houve crashes sob Kickstart 1.3 que desapareceram com a troca para Kickstart 3.1; no EATX2000 o cartão só inicializou após remoção de algumas placas; na B2000 modificada um circuito de supervisão de tensão alterado impediu o release correto de /HALT, sendo necessário reverter a modificação.
Entre as limitações documentadas está a ausência de DMA direto ao Fast RAM: como a memória é gerida internamente pelo FPGA, dispositivos que usam DMA no barramento Zorro II não conseguem acessar diretamente essa região, o que pode travar transferências. O projeto recomenda um valor de Mask para o mountlist (0x001FFFFE) como mitigação para certas configurações de disco, mas suporte completo a DMA exigiria mudanças na interface de barramento e no controlador de memória do FPGA.
Outros pontos em aberto mencionados no material incluem modo passivo não testado, confirmação incompleta para Rämixx500 e falhas intermitentes quando Autoconfig é desativado deliberadamente. Segundo a conversa registrada por CRG, não há planos imediatos para implementar FPU ou núcleos 68020/68030, e o FPGA tem pouco espaço de frequência adicional.
O Base64 ilustra que substituir o 68000 envolve muito mais do que um núcleo em FPGA: sincronização de clocks, tradução de níveis, decodificação de memória, Autoconfig, acesso a armazenamento e comportamento de reset são todos essenciais para integração correta com hardware de quase quatro décadas atrás. Quem quiser acompanhar os detalhes de montagem, testes e arquivos de gateware pode consultar os repositórios e a documentação públicos do projeto, bem como o vídeo com a investigação completa realizado por CRG.
Fonte: The Oasis BBS