Quais são as vantagens / desvantagens de usar retro hardware vs. emulação FPGA vs. emulação de software? [fechado]

Uma vantagem que os emuladores FPGA geralmente compartilham com o hardware vintage é a capacidade de usar dispositivos que interagem com o hardware de maneiras que dependem muito do tempo. Por exemplo, se houver um cartucho de jogo para o NES que dispara uma interrupção toda vez que a primeira linha de dados de um sprite em particular é buscada, um console que lê o conteúdo de um cartucho e o emula somente seria capaz de jogar o jogo corretamente se fosse capaz de reconhecer o que o cartucho estava fazendo com a linha de interrupção.

O hardware baseado em FPGA geralmente funcionaria tão bem quanto, se não mais mais confiável do que hardware vintage, mas existem algumas peculiaridades estranhas a se ter em mente. Alguns protótipos de cartucho de expansão para o Atari 2600, por exemplo, contavam com o fato de que, mesmo quando o NMOS 6502 está tentando aumentar o volume do barramento de dados, é incapaz de tentar com força suficiente para dominar um dispositivo externo que está tentando puxe a linha para baixo, nem se danifique na tentativa. Observe que o inverso não é verdadeiro: um dispositivo NMOS que tenta puxar uma linha para baixo enquanto um dispositivo externo está puxando para cima pode se danificar na tentativa (RIP 2600jr). Se alguém fosse conectar em um sistema de recreação moderno um dispositivo NMOS que dependesse da capacidade de sobrecarregar os fios do barramento e o sistema não limitar a corrente de acionamento do lado alto nesses fios, ele poderia danificar o dispositivo externo. Não sei até que ponto isso seria realmente um problema, mas como todos os dispositivos que dependem de tais técnicas são provavelmente raros, seria muito lamentável se eles fossem danificados.

Outro problema potencial é que os eletrônicos antigos eram frequentemente bastante lento para responder aos sinais, o que significava que se um dispositivo emitisse um sinal em um fio muito brevemente, ele provavelmente seria ignorado. Alguns eletrônicos antigos às vezes produziriam pulsos de glitch breves se alguma combinação de entradas mudasse entre um estado em que a saída deveria ser baixa e um estado diferente em que a saída deveria ser baixa. Se uma recriação de FPGA não for projetada para ignorar esses pulsos, eles podem causar operação incorreta no hardware recriado, embora não tenham causado problemas no original.

Pessoalmente, acho que FPGAs são a melhor maneira de recriar sistemas. Hardware vintage é legal, mas a confiabilidade costuma ser problemática. A emulação de software pode funcionar muito bem, mas ficará limitada à interface com o hardware que o designer do emulador conhece. Uma boa recreação baseada em FPGA pode interagir com quase qualquer tipo de vintage hardware, incluindo dispositivos sobre os quais o designer FPGA não sabe nada , ao mesmo tempo que oferece mais confiabilidade do que hardware vintage.

Prefácio: A questão parece pedir opiniões, já que é opinião se alguém aceita uma emulação, não importa se o software está em uma CPU ou em um FPGA, igual ao real ou não.

Pergunte a si mesmo, está dirigindo um carro de tecnologia moderna pimped up to look como um SSK é o mesmo que dirigir um carro real? Você quer dirigir uma BMW dos anos 1950 com todos os seus sons, cheiros e vibrações (e todos os ajustes necessários para mantê-la funcionando) ou uma bicicleta elétrica 2020 feita para se parecer com uma, dando-lhe o som clássico de uma construção no iPod ?

Estou indagando sobre quais são as diferenças entre usar um hardware real, emuladores de hardware baseados em FPGA como o MiSTer e a grande quantidade de software emuladores para diferentes sistemas executados em computadores modernos com Windows, MacOS e Linux.

Se você é apenas um usuário, convenceu-se de usar seu teclado e mouse modernos lidar com alguma imagem, que parece 640 x 400, na sua tela 4k, então o software é tudo que você precisa. Já uma versão FPGA será um exagero, pois usa os mesmos dispositivos modernos.

Por outro lado , se a imagem não for suficiente, mas você quiser sentir o volumoso mouse Atari, o ondulante teclado Amiga ou o volumoso joystick C64, todos apresentados com brilho CRT real, então não há outra maneira de e obter a coisa real.

Uma coisa que me veio à mente é que os emuladores de software e hardware podem não ser precisos o suficiente

Agora eles estão. em cada detalhe. O hardware moderno é rápido o suficiente para permitir o uso do software HLL para obter o tempo exato do ciclo. Especialmente quando all in e output são emulados de qualquer maneira, mapeados para dispositivos modernos.

Mas isso me parece algo dependendo da qualidade da implementação que pode variam entre diferentes emuladores e melhoram com o tempo devido à correção de bugs, mas não como um problema fundamental.

Programação e manutenção lentas não invalidam a abordagem. Para todos os efeitos, exceto hardware real, não há diferença.

Também estou ouvindo sobre o problema de latência com os emuladores de software, mas eu “Estou um pouco surpreso que algo assim realmente possa ser sentido em um computador que é provavelmente milhões de vezes mais rápido do que a máquina emulada.

Talvez cem vezes, se for o caso. Lembre-se de que a maioria dos componentes principais não ficou tão mais rápida – e a maior parte disso foi consumida por dispositivos de tamanho maior e necessidades de dados.

O problema da latência é algo que existe desde sempre. Haverá sempre alguns afirmando que podem ver / sentir a diferença. Embora isso possa ser verdade em algumas situações muito dedicadas, é uma porcaria na maioria das vezes. Alegar sentir alguns microssegundos, ao testar um joystick já pode custar mais é simplesmente fantasia.

Existe realmente uma razão técnica para preferir hardware real ou emulação baseada em FPGA versus emulação de software

O que constitui uma razão técnica para você? Em si, o termo não é claro ao comparar diferentes implementações completas.

ou isso é apenas uma coisa nostalgia, causada pelo desejo de preencher como você estão realmente de volta aos anos 80 ou 90?

Você já se sentou na frente de uma das máquinas antigas? É surpreendente como diferentes teclados sentem quando deixam o equipamento padronizado de hoje.

E então há, é claro, os ajustes de hardware – não é muito divertido com emuladores, já que adicionar uma interface é apenas adicionar algumas linhas de código – ou apenas configurati em alguns casos. Sem layout, sem gravação, sem solda e especialmente sem amaldiçoar e remendar até que funcione.

Eu “gostaria de esclarecer o termo “emulação FPGA” mencionado na pergunta.

Em primeiro lugar, é claro que existe algo como emulação de software. Tomemos como exemplo alguns (mais ou menos) emuladores de software exatos da CPU 6502 . Eles tentam emular todos os artefatos externos da CPU real, como número de ciclos por cada comando, endereços dos acessos à memória e até mesmo “estado interno” (ao invés, apenas o estado dos registradores visíveis por software). No entanto, ele não tem nada parecido com a CPU real, começando do ponto em que é pura questão de software, não dispositivo de hardware.

Quando qualquer novo recurso do 6502 real é descoberto (como novos opcodes não documentados ou sinalizadores ou detalhes de execução ), ele é inserido no emulador de software como “outro recurso a ser implementado”. Nenhum recurso da coisa real seria incluído no emulador de software, se fossem desconhecidos pelo implementador.

Então, vamos dar uma olhada nos núcleos HDL compatíveis com 6502.Eles agora representam um dispositivo lógico digital real – ou um modelo disso (no caso do HDL ser simulado, não implementado no hardware real como FPGA ou ASIC). Eles agora têm armazenamento flipflop (ou latch) real para os registradores da CPU, podem implementar sinais de barramento da CPU reais e até mesmo ser inseridos no computador retro em vez do 6502. No entanto, são feitos (mais ou menos) “do zero”, com as especificações da CPU que pretendem substituir, não sua estrutura interna. E ainda faltariam recursos não descritos nessas especificações, que existem na CPU retro real, mas ainda são desconhecidos para o implementador.

Outro nível de reconstrução poderia ser o design HDL construído da seguinte maneira:

1. CPU retro real é decapitada e fotografada
2. então netlist e esquemas em nível de transistor são recriados (manualmente ou por algumas ferramentas mais ou menos automatizadas)
3. netlist é convertido para o esquema de nível de porta e então para descrição HDL, que por sua vez é implementado em FPGA ou ASIC.

Diferente dos casos anteriores, agora quase todos os recursos da CPU real sejam implementados “nativamente”, porque a estrutura do HDL resultante é mais ou menos equivalente à estrutura da coisa real (no nível das portas lógicas e flipflops).

Ainda pode haver problemas, por exemplo 6502 tem algumas instruções que se comportam de maneira errática e sinto que esse comportamento não surgiria em HDL naturalmente.

De um modo geral, considero er tudo acima de “engenharia reversa e, em seguida, recriar HDL” é na verdade uma emulação , seja em software ou hardware, enquanto a última forma não .

Em outras palavras, vamos considerar a preservação do software antigo. Poderíamos executá-lo em hardware contemporâneo, mas se não estiver disponível, emuladores de software entram em ação, mas o software antigo que eles são usados para executar ainda é exatamente o mesmo.

Agora, gostaríamos de preservar a parte antiga do hardware (CPU), mas sua implementação autêntica não está disponível, portanto, nós a recriamos usando uma tecnologia mais recente, mas a estrutura lógica da CPU permanece exatamente a mesma.

Para oferecer uma resposta sobre a questão da latência apenas, como um autor emulador:

Exceções abundam, mas a regra geral no hardware original dos “anos 80 e posteriores o início dos anos 90 é que as alterações de entrada de joypad e teclado podem ser detectadas pelo hardware quase imediatamente após acontecerem, e que conforme a saída de vídeo e áudio da máquina chega ao usuário quase imediatamente – por exemplo, para uma televisão CRT clássica, o nível do raster está pintando agora é quase a saída ao vivo da máquina.

Com o hardware agora, a entrada geralmente atravessa es uma pilha Bluetooth ou USB, que pode ser inspecionada apenas em um determinado intervalo pelo sistema operacional host e, se algo acontecer, ele comunica isso ao processo interessado, o que pode ou não acontecer imediatamente, dependendo do programador específico.

Muitos emuladores também implementam um loop principal que se parece com a forma como você pode criar um jogo:

1. coletar todas as entradas mais recentes e encaminhá-las para a máquina emulada;
2. execute a máquina para obter um quadro;
3. pinte o próximo quadro de saída em um buffer invisível;
4. coloque isso na fila para exibição no próximo vsync e bloco;
5. repita.

Para fins de argumentação, imagine que sua máquina moderna seja muito rápida e que as etapas 2 e 3 sejam instantâneas. Então:

• há uma média de meio frame de latência de entrada mais qualquer sinalização Bluetooth / USB e o sistema operacional adicionado – qualquer entrada que ocorrer logo após o topo de um frame não será encaminhada até o início do próximo, qualquer coisa que ocorra bem no final será comunicada quase no momento certo, e a faixa de latências entre é linear, então a média está no meio; e
• há um quadro adicional fixo de latência de saída porque você publica um quadro para apresentação no próximo vsync e espera até que seja a hora de ser mostrado.

Então, com aquele loop simples, no hardware ideal, no caso médio, o atraso entre você pressionar algo e a tela reagir é cerca de 1,5 quadros a mais do que o hardware real. E isso só se o host e as máquinas emuladas estiverem funcionando na mesma taxa de quadros .

Os puristas argumentam que alguns jogos originais são tão bem ajustados, após o número apropriado de horas de testes e ajustes durante o dia, que 1,5 frames os coloca em desvantagem que eles podem detectar.

FPGAs geralmente são * emulações, não importa como sejam vendidos, porque geralmente são uma pessoa que reimplementa uma especificação em uma linguagem de descrição de hardware de alto nível. Mas eles procuram omitir o máximo possível dessa latência – um de boa qualidade omitirá totalmente o buffer de vídeo, executará o resto do sistema em tempo real e enviará a entrada com o mínimo de atraso.

* qualificação adicionado de acordo com a correção fornecida por @lvd abaixo. Veja sua resposta para mais cores.

Claro, não é difícil consertar a maioria dos problemas de software no software:

• encaminhar a entrada com mais frequência;
• não use vsync para acionar uma nova saída para vsync; e
• não use um buffer duplo.

In extremis, você pode até correr o raster para latência de saída semelhante a um FPGA – se você já tiver um alto – loop de freqüência para entrada freqüente, e se o hardware base suportar qualquer tipo de saída que possa produzir quebra de tela, então você tem as ferramentas.

Infelizmente, tais abordagens não eram geralmente utilizadas por emuladores no passado, especialmente antes que a latência se tornasse um tópico amplamente discutido, e algo como uma imagem negativa travasse.

Comentários

• FPGA nem sempre é um emulação, pelo menos em seus termos de " uma pessoa reimplementando uma especificação em uma linguagem de descrição de hardware de alto nível "
• @lvd para melhorar a resposta, você pode ser mais específico? Eu ' estou ciente de um experimento que usou uma netlist extraída por VisualChips de um real (se a memória não funcionar ) TIA, mas pouco além disso. EDITAR: não, espere, vejo que você ' postou uma resposta separada. Obrigado!

muitos aspectos do HW vs SW foram cobertos por outros posts aqui, então eu irei não toque neles. Em vez disso, gostaria de explicar o problema de LATÊNCIA do meu ponto de vista, juntamente com a experiência que adquiri durante a codificação de meus emuladores para várias plataformas …

Fazer o emulador de SW em máquinas modernas é muito mais difícil do ponto de vista de latência do que era nos tempos de acesso de E / S direto. Para computadores domésticos e consoles de jogos, precisamos simular / emular som, saída visual e entrada do usuário com a maior precisão possível. O maior problema é com o som. Isso ocorre porque nossa audição é muito melhor do que qualquer outro de nossos sentidos e podemos sentir / ouvir a diferença se o som estiver desligado por poucos ms ou Hz. Se a tela estiver desligada por 1 ou 2 quadros, não podemos ver a diferença. Além disso, se a entrada atrasar um pouco, está tudo bem (para a maioria dos humanos).

Na arquitetura de máquina moderna, tudo é armazenado em buffer (especialmente som). Portanto, para produzir som, precisamos criar um PCM dados que são enviados para o chip de som e reproduzidos por DMA + DAC . Para fazer isso, geralmente são usados 2 buffers circulares ou muitos pequenos buffers lineares. Agora, para produzir sons sem falhas, os buffers devem ser grandes o suficiente. Por exemplo, no Windows da última vez que verifiquei WAVEOUT precisa de pelo menos 20-80 ms. DirectSound necessita >400 ms

Agora, se o programa emulado se ajustar saída de som, ela será emitida somente depois que o som já pesquisado for reproduzido.

O mesmo vale para a entrada de E / S em algumas plataformas, portanto, os atrasos se somam.

Quando você usa FPGA então você tem acesso direto à saída de som sem nenhum buffer. O mesmo vale para a entrada.

No entanto, a latência de entrada do jogo (teclado, joystick) geralmente não tem nada a ver com a latência do sistema host . A causa comum é que a maioria dos emuladores usa tiques de relógio para manter as velocidades emuladas. Assim, eles simulam a CPU ou qualquer outra coisa e, uma vez que alcançam o número desejado de relógios simulados por vez, eles dormem até o próximo temporizador ser emitido ou qualquer outra coisa. Quanto mais rápido o computador host, menor o tempo que ele precisa para emular, portanto, a simulação não reagirá na maior parte do tempo real.

Por exemplo, vamos supor que nossa simulação pode ser executada 100x mais rápido do que a velocidade original do computador emulado. Isso significa que apenas 1% do tempo a simulação está fazendo algo e o resto é apenas Sleep(). Durante o sono, a emulação não responde a nada. Portanto, ele pode perder toques de tecla, disparar cliques, etc … Para remediar que alguns emuladores podem usar o buffer novamente levando à latência em vez de ignorar a entrada. Existem também diferentes estilos de controle de tempo que eliminam completamente esse problema. Para obter mais informações sobre este assunto, consulte:

• Pergunta sobre a precisão da contagem cíclica ao emular uma CPU

Máquinas NTSC vintage (e Macs CRT, etc.) podem alterar sua saída de gráficos no meio da atualização da tela CRT (parcialmente raster vertical), rasgando a imagem em resposta à entrada em tempo real.

Emuladores que usam monitores não CRT não podem fazer isso em tempo real e só podem simular um raster rasgado no próximo quadro ou campo.

E a única maneira de testar se uma emulação é precisa compará-la com hardware vintage real (de verdade). Veja se há armadilhas lógicas ocultas não documentadas (desfusão, etc.) ou bugs de layout analógico nas várias camadas do chip ASIC.

Comentários

• _ " .. só pode fingir … " _Qual é a diferença? Não é ' uma emulação sobre falsificar a coisa toda?
• Não em um monitor não CRT. Um LCD (et.al.) não ' atualiza em 2 campos entrelaçados de 30 quadros, onde linhas alternadas e a parte superior e inferior de uma janela aparecem em momentos diferentes, acima de 10 ms separados em tempo real. Talvez um FPGA alimentando um monitor CRT antigo fosse mais preciso do que um emulador.
• Nada impede o software do emulador de fazer o mesmo. e alguns sim. Afinal, as telas de 60 Hz são padrão agora, permitindo transferir a mesma cintilação de um CRT. Não há necessidade de software baseado em FPGA ou CRT aqui.