Como é possível que este console “Polymega ™” “não suporte” Everdrives?
Estou lendo aqui: https://polymega.com/faq/
O EVERDRIVES, OS GÊNEROS DO JOGO E OS MULTI-JOGOS FUNCIONARÃO COM O POLYMEGA ™?
Polymega ™ não é compatível com Game Genies ou Everdrives.
Como isso é possível? O que há para "apoiar"? Um Everdrive é apenas um cartucho que para o console se parece com qualquer cartucho, não é? Ele está ativamente (de alguma forma) detectando isso e bloqueando-o ou o que significam?
Respostas
Você está nos pedindo para especular sobre algo que ainda não foi lançado.
No entanto, olhando para o FAQ, fica claro que esta é apenas uma caixa bonita do Linux com alguns emuladores.
Processador: Processador Intel Coffee Lake S Series
Memória: 2 GB DDR4 RAM
Os Módulos da Polymega usam emuladores de primeira linha com entradas de controlador de baixa latência.
Emuladores: versões legalmente licenciadas do Mednafen, Mesen, Kega Fusion e MAME com correções de bugs adicionais, desenvolvimento de BIOS de CD e YM2610 substituído pelo CD Neo Geo da Playmaji.
A partir do texto de marketing e das perguntas frequentes, fica claro que eles querem que você copie seus cartuchos para o armazenamento interno (ou compre-os de qualquer parceiro que eles arranjaram) e os reproduza a partir daí.
Em outras palavras, é um Ouya mais rápido.
Então, como ele 'daria suporte' aos cartuchos existentes?
Para reproduzir os cartuchos existentes em um emulador, eles primeiro precisam ser despejados na RAM. Para fazer isso, os fabricantes precisam desenvolver uma interface compatível com os cartuchos apenas na medida em que o conteúdo de sua ROM possa ser lido. Para os jogos Genesis, isso pode ser tão simples quanto ler a máscara ROM em um bloco linear. Para jogos de Game Boy e Master System, isso envolve negociação com o chip mapeador. Este estágio pode ser implementado com relativa facilidade para a maioria dos consoles.
Para o usuário final, eles colocam um carrinho e jogam o jogo. É transparente para eles: parece um console, e eles ficarão satisfeitos. O slot de cartucho quase certamente não é usado durante o jogo normal neste sistema. *
A distinção importante é que a interface de leitura não precisa ser particularmente rápida. Para executar um jogo diretamente de um cartucho, é necessário acessar os dados e agir em tempo real. Despejar um cartucho pode ser feito com calma.
* Ler e gravar a memória RAM salva em um carrinho pode ser um tanto simples, embora precise ser testado jogo a jogo, uma vez que não é homogêneo (pelo menos no Genesis). Impressionante se eles se importarem. :)
Como ser um emulador 'interrompe' o funcionamento dos Game Genies e Everdrives?
Everdrives, Game Raccoons, etc. fazem interface com hardware externo, como os próprios cartões (micro /) SD, e têm peculiaridades além da interface Nintendo / Sega padrão que não é emulada na maioria dos emuladores - troca de banco de memória Flash, etc. Se os fabricantes deste Linux o console não programou suporte para estes, ele não existe. Não vem de graça. E o suporte, neste caso, seria algum tipo de passagem de software bidirecional do menu Everdrive emulado para o carrinho real ...? Porque se importar?
Se este fosse um console baseado em hardware, usando FPGA ou chips reais, ele poderia reproduzir a interface de barramento e tempo exatos, você teria compatibilidade com salvar RAM, chips de aprimoramento, Game Boy Camera, relógios em tempo real e similares através disso interface. A situação é muito semelhante a "Como o Everdrive lida com todos os chips e coisas especiais que foram colocados nos cartuchos?" , exceto ao contrário: o console substituto teria que falar corretamente com todos os chips reais de aprimoramento.
Haveria poucos motivos para os fabricantes desse console baseado em emulador Linux oferecerem suporte a isso, dada sua abordagem de monetização declarada.
É muito mais provável que eles suportem um Game Genie simulado em seu console emulado , já que o suporte a cheat virá como padrão no conjunto de emuladores que eles pegaram, mas isso é tudo.
Você se viu confundindo o conceito de "obras" e "suportes".
"Suportado" geralmente significa que o fornecedor está disposto a resolver quaisquer problemas que surjam.
O código que escrevo pode parecer "funcionar" em certas situações, mas isso não significa que devo "apoiar" essas situações - geralmente porque não tenho a capacidade de reproduzir quaisquer problemas que você possa encontrar ou não testei adequadamente esse ambiente e, portanto, não posso dizer que os "apoio".
Muitos consoles de recriação NES funcionam lendo todo o conteúdo de um cartucho na inicialização e, em seguida, reproduzindo os dados copiados em um emulador, exceto que se o emulador reconhecer ações que deveriam gravar em um armazenamento não volátil em um cartucho, ele pode usar o hardware para atualizar o conteúdo do cartucho instalado fisicamente.
A principal limitação desta abordagem, e com a emulação baseada em software em geral, é que enquanto um processador moderno como um ARM pode emular instruções 6502 em média muito mais rápido do que um 6502 real poderia executá-las, ele não pode atingir esse desempenho com cada operação individual . Geralmente, os emuladores processam uma sequência de instruções que não envolvem nenhuma atualização de exibição ou som muito mais rápido do que um 6502, mas precisam gastar algum tempo processando atualizações de exibição sem executar nenhuma instrução. Isso é bom se o emulador não tiver que interagir com o hardware real enquanto isso está acontecendo, mas não ao usar cartuchos reais "ativos".
Se o software em um cartucho esperasse enviar um comando ao cartucho que permitiria à CPU buscar e executar 59.552 bytes / quadro de conteúdo que não foi lido do cartucho anteriormente, a única maneira de isso acontecer seria se o hardware pode acessar bytes do cartucho a cada 139,6 nanossegundos. Se o emulador soubesse quais dados o cartucho relataria, ele poderia ser capaz de processar esses dados mais rápido em média e, assim, processar todos os 59.552 bytes em um tempo de quadro, mesmo que às vezes estivesse ocupado por um milissegundo processando gráficos ou som sem emular nenhum instruções. Se o emulador não tiver os dados disponíveis, no entanto, sua velocidade de pico será limitada à taxa de 139 ns / byte que os cartuchos foram projetados para suportar.
Alguns consoles de recreação NES usam um tipo diferente de chip chamado FPGA. Um FPGA ("field programmable gate array") é um dispositivo que se sobrepõe a duas camadas funcionais de circuitos: uma coleção de elementos lógicos que são conectados por grades de fios conectados por interruptores e algum hardware de "programação" que pode fechar seletivamente os interruptores em vários pontos de conexão. Ao contrário de uma CPU que realiza uma tarefa (ou, para uma CPU multi-core, algumas tarefas) de cada vez, todas as partes de um FPGA podem operar simultaneamente. Como resultado, uma recriação do NES baseada em FPGA seria capaz de realizar todas as operações individuais precisamente na mesma velocidade de um NES real.
Embora o Everdrive seja um cartucho em vez de um console, ele usa um FPGA para recriar o comportamento de uma ampla gama de cartuchos de jogos com temporizações que correspondem ao original. Além disso, se houver um cartucho cujo comportamento não é compreendido pelo Everdrive hoje, seu FPGA pode ser reconfigurado para se comportar como o original, alimentando-o com um "mapa de fusíveis" diferente [conjunto de informações sobre quais opções de configuração abrir e fechar]. Embora seja possível projetar um console baseado em emulador (não FPGA) para funcionar com um Everdrive para carregar jogos cujo comportamento físico o emulador entende, não haveria como acomodar um jogo cujo comportamento do cartucho ele não entendia, mas para o qual o Everdrive tinha um mapa de fusíveis.