Ilustrações de snes vs genesis

Acho que o Thiago já disse quase tudo, mas ainda assim é uma pergunta interessante para mim, então darei minha própria resposta. Muitas pessoas simplesmente comparam o 68000 (CPU Megadrive) contra o 65816 (CPU SNES) apenas na velocidade do relógio e rapidamente assumem que o MD é duas vezes mais rápido que o SNES por causa disso (7,67 MHz versus 3,58 MHz). Na verdade, você não pode comparar essas CPUs dessa maneira porque elas funcionam de uma maneira completamente diferente. O 65816 é capaz de acessar a memória a cada ciclo quando o 68000 requer 4 ciclos para isso e, geralmente, as instruções do 68000 levam muito mais ciclos para serem executadas do que as 65816. Essa é a razão da lenta velocidade da CPU do SNES, de fato com a ROM clássica e, ao acessar a RAM principal, a CPU do SNES só pode rodar a 2,68 mhz. Somente a ROM rápida permite atingir a velocidade de 3,58 MHz (e a ROM rápida chegou tarde na vida do sistema). E mesmo a 2,68 MHz, você já está acima da velocidade da memória 68000, que é 7,67 / 4 = 1,92mhz…

Portanto, saiba que você pode pensar que a CPU do SNES tem vantagem, mas o fato é que a CPU do SNES usa um barramento de dados de 8 bits quando o 68000 possui um de 16 bits, mas a diferença mais importante na tecnologia é a própria CPU. O 65816 é baseado na arquitetura 6502 simples e barata, estendida para lidar com operações de 16 bits, ainda que a CPU esteja mais próxima da arquitetura de 8 bits por sua simplicidade e acesso à memória. 68000, por outro lado, se um híbrido de 16/32 bits com um conjunto de instruções muito mais avançado e capaz, torna a CPU muito mais eficiente. Então, no final, o 68000 teve vantagem por uma margem importante. Eu acho que é duas vezes mais rápido que a CPU do SNES, não por causa da diferença de velocidade do relógio, mas por causa da arquitetura.

O professor da Motorola 68K da Sega Genesis teve um clock de 7Mhz versus o processador Super NES que teve um clock de 3,58MHz. Embora o Genesis fosse considerado a potência da época, algumas de suas vantagens incluíam jogabilidade mais suave, o que o tornava o console superior quando se tratava de jogos esportivos. Enquanto o Super NES não tinha poder de processamento, ele compensava seus gráficos e sons, e na verdade o Super NES tinha quase duas vezes mais memória RAM! (72 vs. 128kb) O Super NES tinha recursos de escala e rotação integrados. Quando joguei Super Mario Kart no Super NES, não conseguia imaginá-lo rodando no Genesis. O poder de processamento não significa nada, enquanto o Genesis correu mais suave do que os melhores gráficos do que o Super Nintendo, ambos eram excelentes consoles de jogos na época.

Em velocidade, o Genesis foi mais rápido, com clock de 7.67 MHz. A velocidade do processador SNES era de 1,79-3,58 MHz (geralmente 2,68 MHz).

Velocidade não é tudo, porém, aqui estão mais algumas especificações que podem diferenciar o Genesis e o SNES. Vamos começar com o Genesis, 64kb de RAM, 512 cores possíveis (oscilações permitem a aparência de mais), 64 cores simultâneas possíveis e para os painéis da tela: 2 camadas de rolagem, 1 camada de sprite, 1 plano de janela. O Genesis pode ter 80 sprites simultâneos com um tamanho máximo de 32x32. A resolução é 320x224 constante. O SNES que você encontrará possui 128kb de RAM, 32.768 (contando alfa) cores possíveis, 256 cores simultâneas possíveis e para os painéis da tela: 1-4 camadas com usos variados, dependendo do modo (0-7). O SNES pode ter 128 sprites simultâneos com um tamanho máximo de 64x64. A resolução é de 256x224 a 512x448.

Portanto, como você pode ver nos dados acima, mesmo que o Genesis fosse mais rápido, o processador SNES era mais poderoso.

O Mega Drive era muito, muito mais poderoso que o SNES, e depende de DMA, PPU e CPU.

Se você vai comparar os sistemas, é justo excluir coprocessadores de cartuchos que viram a Nintendo continuar com sua política de transferir custos para terceiros com coprocessadores de cartuchos adicionais, como a linha SuperFX. Portanto, o SNES foi projetado, como o NES, para utilizar co-processadores para jogos com mais uso intensivo de processador.

Somente a Virtua Racing no SMD usou um co-processador que era muito mais poderoso que os chips SuperFX, mas, como no chip SuperFX, aumentou o preço do cartucho. Um Mega Drive básico (smd) pode empurrar quase tantos polígonos quanto o chip SuperFX original, que pode ser visto em comparações em jogos como o Stunt Racer.

Como mencionado acima, o SNES é uma variante 6502 da MOS Technology, composta por funcionários da equipe 65000 da Motoroller, que saíram para criar sua própria variante de orçamento 68000, o 6502 como Motoroller achou que competiria com seu 68000 cpu. Portanto, embora o 6502 fosse mais eficiente por ciclo de clock, era menos flexível e oferecia problemas aos programadores devido a um conjunto limitado de instruções e muito menos registros. Embora a variante SNES 6502 (Ricoh 5A22) ofereça um conjunto de instruções avançadas em relação aos 6502 originais, ainda era muito menos abrangente que o 68000. Os 68000 também usavam registros internos de 32 bits nos internos de 16 bits do SNES, bem como um barramento de dados de 16 bits. para os 8 bits do SNES. Isso significa que o dobro dos cálculos é possível, por ciclo de clock no processador 68000 em comparação com o 5A22. Embora como mencionado acima, o 5A22 é capaz de tempos mais rápidos a cada 2,3 ou 4 ciclos, até as interrupções de tempo de 4 ciclos do 68000, embora para tirar proveito dos recursos avançados do chip Ricoh necessários no conhecimento profundo do MOS menos conhecido CPU.

Mas a principal diferença estava na largura de banda da memória das unidades DMA (acesso direto à memória) do sistema. O circuito integrado SEGA-Yamaha IC6 permitia que os dados viajassem do cartucho rom diretamente para a ram do VDP (processador de vídeo a 13Mhz) e o processador de som YM2612 (com clock para a CPU a 7,6Mhz), ignorando o processador principal - liberando são ciclos para lógica de jogo ou outras tarefas.

O DMA externo de 16 bits do Mega Drive funcionava em torno de 29Mbps no geral, com velocidades associadas às velocidades de relógio nominais de várias unidades de 13Mhz / Mbps para a unidade VDP e 3Mhz / Mbps no chip Z80 do controlador de som (@ 3,5Mhz).

O problema com o design do circuito do SNES é que o som, o vídeo e a CPU são executados independentemente do loop principal da CPU / memória; portanto, os dados do carrinho precisam interromper os ciclos do clock da CPU para mover os dados da ROM e passá-los para a ram de áudio ou vídeo. Esse foi um problema que foi agravado pelo uso de áudio de 15 bits em cores e pcm, os quais exigiram maiores quantidades de dados em comparação com o áudio de síntese e fm em cores de 9 bits e smd do smd.

Foi alegado acima que as PPUs do SNES (unidades de processamento de imagens) eram mais poderosas que o vdp do smd, mas isso não é exato. Os SNES PPU (1 e 2) estavam intimamente integrados, mas rodavam de forma independente e eram necessariamente cronometrados na velocidade do clock do processador principal, que era nominal de 3,5 MHz. Portanto, a velocidade máxima potencial do PPU1 e PPU2 em execução em tandem foi de 8Mhz ao vDP de 13Mhz do smd. Embora, devido ao funcionamento da PPU separadamente, nenhuma PPU possa exceder a velocidade do clock da CPU, por isso seria necessária uma programação altamente complexa para atingir esse limite teórico de 8Mhz. Efeitos como transparência, escala e rotação de segundo plano consumiriam ciclos de relógio e não são "livres", como mencionado acima.

Por fim, a eficiência interna do registrador 32bit 68000 foi aproximadamente o dobro do registrador 5bit22 de 16 bits e executou a 27Mbps redondos.

Em resumo, a alta profundidade de bits da paleta de cores do SNES, o barramento externo de 8 bits e o som ADPCM significaram que o carregamento de gráficos e sons na memória diminuiu consideravelmente a velocidade da máquina em comparação com profundidades de bits mais baixas e som fm, mas a localização da unidade dma no cpu 5A22 reduziria a velocidade da máquina para jogos exigentes para todos, exceto os programadores mais talentosos (Compile).

O potencial do Mega Drive, como todas as máquinas SEGA, nunca foi totalmente explorado e o hardware contido no smd o tornou facilmente o mais poderoso hardware de jogos domésticos no momento do lançamento (fora das cidades japonesas FM Xes e X68000). Algo que não aconteceu novamente antes do Dreamcast. O XBOX e o PS2 e tudo o que faltavam em seguida foram comparados com os PCs acessíveis ao mesmo tempo disponíveis com placas de aceleração gráfica.

Também é notável que o SNES execute todos, exceto alguns jogos em 256x240 (aspecto 8: 7), para o 320x240 (aspecto 4: 3) do smd, o que significa que quase todos os jogos movem cerca de 30% mais pixels a qualquer momento. Além disso, é mencionado que o SNES ofereceu blocos de sprite de 64x64 e, portanto, poderia mover sprites maiores de forma mais eficiente, mas isso não é preciso, pois a combinação do tamanho máximo de sprite do smd de 32x32 em paralelo poderia alcançar o mesmo efeito com carga comparável no vdp, mas muito mais importante, o smd ofereceu uma variedade muito maior de tamanhos de sprites (16 variações e 16 tipos na tela), o que permitiu um uso mais eficiente de sprites devido ao fato de alguns sprites não serem quadrados, enquanto o SNES permitia apenas quatro tamanhos: 8x8, 16x16, 32x32 e 64x64 (2 tamanhos na tela).

Os únicos jogos que eu conheço que rodavam em 320x480 (modo entrelaçado) no smd eram os modos de tela dividida Sonic 2 e 3 e eram feitos a 60fps e com muita ação.

Então, em suma. A Nintendo vendeu seus clientes com cpu, profundidade de cor e som pcm, o que era impraticável para os chipsets e transferiu os custos dos coprocessadores para terceiros para obter jogos que os clientes esperavam a partir do período.

Sega Mega Drive / Especificações técnicasSega Mega Drive / Comparação de hardware

Muitos fatores são importantes quando se compara diferentes processadores (e arquiteturas diferentes), não apenas a velocidade da CPU. O processador 68000 da Genesis e o processador 65c816 do SNES não eram nada similares em filosofia, o que complicou ainda mais as comparações. Mas do ponto de vista prático do desenvolvimento, o processador 68000 foi percebido como mais fácil de programar, e a arquitetura do Genesis permitiu mais cálculos e embaralhamento de dados do que o processador do SNES, com muito menos necessidade de recorrer a truques e / ou processadores extras, como nos ofereceram com o SNES.

A velocidade do relógio deve ser um dos fatores na medição do desempenho, mas como o processador 68000 tinha instruções com tempos de ciclo muito variados, na maioria das vezes, relógio a relógio, o 65c816 pressionava mais instruções por ciclo de relógio, como a maioria das instruções executadas em 3 ou 4 ciclos de clock em comparação com mais de 4 ciclos no 68000. Mas, na arquitetura do SNES, a Nintendo teve que comprometer a velocidade para permitir que cartuchos com velocidades ROM mais lentas funcionassem (reduzindo assim os custos de produção de cartuchos), então eles usavam um relógio variável, de 1.79MHz (para cartuchos LoROM de memória mais baratos) a 2.68MHz (para cartuchos HiROM mais caros) a 3.58MHz (para código na SRAM principal). Por outro lado, os 7,68 MHz do Genesis eram constantes e os recursos de sincronização de uso geral do processador significavam que a SEGA geralmente podia se contentar com a mesma ROM mais barata do LoROM do SNES.

Outro fator para determinar a eficiência é a Largura do barramento - a quantidade de dados que são passados ​​em cada ciclo do relógio. O barramento de dados principal do SNES era de apenas 8 bits, mesmo com um processador completo de 16 bits, portanto, as leituras e gravações completas de 16 bits precisavam levar 2 ciclos cada, em contraste com o barramento completo de 16 bits do Genesis, que movimentava 16 bits de dados em cada relógio. Isso significava que, para a mesma velocidade de clock, o SNES levaria o dobro do tempo para enviar dados ao redor do Genesis. E para finalizar, há o conjunto de instruções. Cada um desses processadores possuía um conjunto de instruções totalmente utilizável, mas como o processador 68000 foi originalmente desenvolvido como um processador para estações de trabalho e mainframes avançados, que possuíam software comumente desenvolvido em linguagens de alto nível, o conjunto de instruções era maior e mais adequado para ferramentas para gerar (que de fato também favoreceram um pouco a montagem codificada à mão), em comparação com o conjunto de instruções concisas de 65c816 derivado do conjunto original do 6502. A quantidade de registros de trabalho no processador também significava que os usuários do conjunto 68000 eram frequentemente menos restritos que os usuários 65c816, pois o primeiro tinha 8 registros de uso geral e outros 8 de endereçamento, onde o último tinha apenas um registro de uso geral (embora com 256 registros indiretos na memória) e 2 registros de endereçamento.

Para finalizar, era de fato a qualidade do código que importava. Mas a configuração da SEGA tornou muito mais fácil obter alto desempenho do que a da Nintendo.

(EDIT: Formatação e correção de alguns erros de digitação)

É realmente difícil responder a isso, porque é uma espécie de comparação entre maçãs e laranjas. O snes PPU (chip gráfico) parece ser muito mais poderoso do que o equivalente a um mega drive, mas a CPU é menos clara. Não tenho uma compreensão clara das peculiaridades de nenhum dos sistemas para dizer isso conclusivamente de uma maneira ou de outra.

Ambos os sistemas foram revisados ​​repetidamente durante o projeto, é claro. De várias coisas que pude encontrar on-line e em documentos técnicos, o designer do Mega Drive se arrependeu de tornar várias partes do design mais flexíveis, pois ele gostaria de ter dado mais recursos mais perto de quando foi lançado, mas ele se projetou como um canto um pouco, e não podia mudar certas coisas.

Os Snes, como originalmente projetados, eram muito caros (como níveis de Neo Geo caros ou piores), portanto, seu design real é um exercício de redução de custos. Um boato que me deparei há alguns minutos atrás afirmou que seu design em um ponto tinha um 10 mhz 68000 cpu. (Nesse caso, dizer que o snes seria mais rápido seria simples, porque é a mesma CPU. Da mesma forma, você pode dizer que um Neo Geo é quase o dobro da velocidade de um mega drive. Bastante incontroverso, porque eles têm o mesmo design de CPU. ) Outra coisa que você vê com o snes é que a PPU tinha muitos recursos que raramente eram usados. Como os modos de 256 cores por bloco e os modos de alta resolução. Algumas dessas eram limitações inerentes que esses modos impunham. (e modo de alta resolução, por exemplo, causando tremulação devido à exibição entrelaçada.). Mas quando você olha para a referência de programação e até a pinagem para os chips PPU, vê que até o hardware final suporta 128 kilobytes de VRAM, embora apenas 64 kilobytes estejam instalados. Isso sugere uma tentativa de corte de custos de última hora, já que metade do carneiro é provavelmente metade do custo. Mas o lado negativo é que os modos de alta resolução e 256 (ou até o modo de cores diretas até 2048) são altamente impraticáveis, pois uma única tela representa quase todo o conteúdo da RAM de vídeo, onde, se tivesse 128 kilobytes, você teria bastante de sobra.

Mas voltando aos sistemas reais, como você define o SNES? Se você começar a contar os chips de expansão encontrados nos cartuchos, que, convenhamos, eram muito comuns (o DSP-1 era usado em asas piloto, que era um título de lançamento em 1990), a questão se torna ainda mais confusa.

O SuperFX (especialmente a segunda revisão) e o SA-1, em particular, fariam muito para mudar a balança.

Isso sem falar no último chip de expansão conhecido que eles planejaram usar (mas nunca o fizeram), que teria sido incluído como parte das últimas revisões do design do CD do Snes, se o tivesse lançado. Esse seria o processador NEC V810 encontrado nos consoles Virtual Boy e NEC PCFX (um processador RISC de 32 bits rodando a cerca de 21 mhz). Se sim, por que ou por que não? E o VDP no Genesis / Mega Drive que fez o Virtua Racer funcionar?

E como você compara algo como o modo 7? O Mega Drive pode imitar esses efeitos na CPU, mas o modo 7 nas snes é basicamente "gratuito", pois o uso não leva quase tempo de CPU para falar, então como você explica isso ao tentar.

E se você começar a olhar para exemplos reais, quanto disso pode ser atribuído a limitações reais de desempenho e quanto é ruim de codificação? Por exemplo, não há nenhuma razão em particular para que os snes acabem com lentidão ao desenhar muitos sprites. É totalmente capaz de desenhar todos os 128 sprites de hardware sem desaceleração, mas muitos jogos exibem desaceleração ruim quando mais de 20 a 30 sprites são visíveis. Isso acontece consideravelmente com menos frequência no Mega Drive, mas também acontece em alguns jogos. Ambos sugerem código mal pensado, em vez de o hardware ser muito lento.

Em muitos casos, os jogos Snes carecem de efeitos gráficos dos quais o hardware é trivialmente capaz, o que novamente não é uma boa indicação de habilidade.

Mas, no final das contas, como você mede os recursos de tais sistemas? Eles fazem as coisas de maneiras diferentes, usando diferentes processadores e chips gráficos. Mesmo algo aparentemente simples como configurar sprites ou planos de fundo exibe uma lógica surpreendentemente diferente, o que sem dúvida tem suas próprias implicações de desempenho. Os snes podem fazer coisas com mais cores do que o mega drive, mas realmente exibi-lo corretamente exige que o sistema faça muito mais trabalho do que o mega drive precisaria para uma cena comparável, mesmo que sob uma observação ingênua possa parecer o que está sendo feito é bem parecido. Enquanto isso, o mega drive possui uma resolução mais alta.

Por linha de verificação, as alterações na rolagem têm suporte explícito ao hardware gráfico no mega drive. (isso faz parecer que há muito mais fundos do que realmente existem). Ambos os sistemas podem fazê-lo (uma técnica muito semelhante é usada conceitualmente no snes para muitos efeitos gráficos), mas o mega drive tem uma função explícita para APENAS ajustes de rolagem no chip gráfico enquanto o snes usa um método HDMA mais geral por scanline para fazer isso e muitos outros efeitos.

Mesmo resultado, métodos diferentes. Um é mais fácil de usar, o outro é mais flexível.

Mas como você pode dizer razoavelmente o que é mais poderoso quando coisas assim estão envolvidas?

Existem demos de tecnologia e até jogos reais mostrando o mega drive criando gráficos 3D baseados em polígonos usando apenas sua CPU. Por outro lado, há pelo menos uma demonstração técnica do SNES fazendo a mesma coisa, então o que isso prova, além de haver muito mais exemplos no mega drive, o que novamente apenas indica que deve ser mais fácil descobrir como fazê-lo com eficiência no Mega drive.

O resultado final é que é muito difícil responder a uma pergunta como essa, a menos que você a restrinja fortemente. (como a que tinha uma CPU mais rápida) Mesmo assim, como as CPUs em questão não são tão parecidas, isso ainda é muito difícil de responder. Muitos benchmarks funcionam testando o desempenho em tarefas específicas. Mas isso influencia os resultados em direção à CPU que executa esse conjunto de tarefas particularmente bem. (e assume que a codificação do benchmark está usando o hardware com eficiência.)

Coisas como o benchmark Dhrystone (que remonta aos dias dos mainframes), por exemplo, dão ao 6502 (o antecessor da CPU snes, como visto no NES e no Commodore 64) como tendo uma classificação de 1,79 MIPS a 3,58 mhz e enquanto o 68000 obtém apenas 1,4 MIPS a 8 mhz. o que implicaria que o 6502 é 2,85 vezes mais eficiente que o 68000. Como é seguro assumir que o 65C816 é mais rápido por ciclo de clock do que seu antecessor, o 6502, devemos assumir por ciclo de clock que o snes é pelo menos 2,85 vezes mais rápido que o mega drive? Afinal, na velocidade 'lenta', o snes tem um processador de 2,68 mhz, enquanto na velocidade 'rápida' é de 3,58 mhz. Enquanto a CPU do mega drive é de 7,6 mhz, com base nas classificações MIPS, a CPU do snes tem uma potência equivalente a cerca de 7,65 mhz no modo lento ou 10,22 mhz no modo rápido.

É isso que os benchmarks de CPU puramente sintéticos parecem implicar. No entanto, a experiência prática com os dois sistemas parece sugerir algo bem diferente.

Então, o que é correto aqui?

Ao verificar minhas fontes, algumas das respostas originais abaixo estão incorretas. Forneci uma versão corrigida abaixo

Corrigido:

Uma coisa a ser observada sobre os snes especificamente a propósito (em referência ao que os outros aqui mencionaram) é que é um design de barramento duplo e possui dois barramentos independentes de 8 bits. O barramento A (conectado à ROM e à RAM do sistema principal), enquanto o barramento B está conectado a praticamente tudo, exceto à RAM do sistema principal, e o controlador DMA não parece fazer parte da CPU. Isso tem algumas implicações peculiares em algumas situações.

O Mega Drive não está muito melhor aqui, dado o objetivo principal da maioria das transferências de DMA, pois qualquer gravação na VRAM deve ser feita como transferências de 8 bits. Transferências para outras partes do sistema podem ser feitas como 16 bits, incluindo os registradores VDP, mas não a VRAM. Na prática, o DMA no Mega Drive / Genesis é um pouco mais rápido, mas nem de longe o sugerido pelo barramento de 8/16 bits.

Original:

Uma coisa a ser observada sobre os snes especificamente a propósito (em referência ao que os outros aqui mencionaram) é que ele é um design de barramento duplo e possui um barramento independente de 16 e 8 bits. O barramento A (conectado à ROM e à RAM do sistema principal) tem 16 bits, enquanto o barramento B está conectado a praticamente tudo, exceto à RAM do sistema principal. Isso significa que as transferências para o PPU do lado da ROM ou da CPU devem ocorrer como transferências de 8 bits, mas a leitura da memória principal ou da ROM pelo processador é leituras de 16 bits.

O Mega Drive não está muito melhor aqui, porque as gravações nos chips gráficos precisam ser feitas através de um conjunto de portas de dados de 8 bits. Portanto, na prática, o resultado final é bastante semelhante nesse sentido.

——————-

Mas ainda assim, a longo prazo, para responder a isso, você realmente precisa ser mais específico em que tipo de pergunta está fazendo. Caso contrário, as respostas raramente farão sentido ou podem ser influenciadas a favorecer um sistema ou outro por razões completamente arbitrárias ...