Pergunta

É o fim de semana, então eu relaxo de passar a programação durante toda a semana escrevendo um projeto de hobby.

Eu escrevi a estrutura de um emulador de CPU do MOS 6502 ontem, os registros, a pilha, a memória e todos os códigos de operações são implementados. (Link para a fonte abaixo)

Eu posso executar manualmente uma série de operações no depurador que escrevi, mas gostaria de carregar uma ROM NES e apenas apontar o balcão do programa em suas instruções, imaginei que essa seria a maneira mais rápida de encontrar opcodes defeituosos.

Escrevi um rápido carregador de ROM NES e carreguei os bancos da ROM na memória da CPU.

O problema é que não sei como os códigos de OPC são codificados. Eu sei que os próprios códigos seguem um padrão de um byte por opcode que identifica exclusivamente o código de opção,

0 - BRK
1 - ORA (D,X)
2 - COP b

etc.

No entanto, não tenho certeza de onde devo encontrar o argumento do OpCode. É o byte seguindo diretamente? Na memória absoluta, suponho que possa não ser um byte, mas um curto.

Alguém está familiarizado com o modelo de memória desta CPU?

EDIT: Eu percebo que isso provavelmente foi filmado no escuro, mas eu esperava que houvesse alguns hackers de maçã e comodoro antigos à espreita aqui.

EDITAR: Obrigado pela sua ajuda a todos. Depois de implementar as mudanças adequadas para alinhar cada operação, a CPU pode carregar e executar o Mario Brothers. Não faz nada além de loop esperando o início, mas é um bom sinal :)

Eu carreguei a fonte:

https://archive.codeplex.com/?p=cpu6502

Se alguém já se perguntou como um emulador funciona, é muito fácil de seguir. Não é otimizado no mínimo, mas, novamente, estou emulando uma CPU que funciona a 2MHz em uma máquina de 2,4 GHz :)

Foi útil?

Solução

O OpCode pega um byte e os operandos estão nos seguintes bytes. Confira a coluna de tamanho de byte aqui, por exemplo.

Outras dicas

Se você olhar em referências como http://www.atarimax.com/jindroush.atari.org/aopc.html, você verá que cada opcode tem uma codificação especificada como:

HEX LEN TIM

O hexadecimal é o seu código de 1 bytes. Imediatamente a seguir é len bytes de seu argumento. Consulte a referência para ver quais são esses argumentos. Os dados do TIM são importantes para os emuladores - é o número de ciclos de relógio que essa instrução leva para executar. Você precisará disso para corrigir seu tempo.

Esses valores (Len, TIM) não são codificados no próprio OPCode. Você precisa armazenar esses dados no seu programa/executador do programa. É apenas uma grande mesa de pesquisa. Ou você pode definir uma mini-língua para codificar os dados e o leitor.

Este livro pode ajudar: http://www.atariarchives.org/mlb/

Além disso, tente examinar qualquer outro 6502 aseembler/simulador/depurador por aí para ver como a montagem é codificada como linguagem de máquina.

Os 6502 manuais estão na web, em vários sites de história. O KIM-1 enviou com eles. Talvez mais neles do que você precisa saber.

As ROMs da Apple II incluíam um dissassoco, acho que é assim que se chamava, e isso mostraria em um bom formato as Opcodes Hex e a Opcode de 3 caracteres e os operandos.

Portanto, dado a pouca memória disponível, eles conseguiram empurrar a contagem de bytes de operando (sempre 0, 1 ou 2) o código de 3 caracteres para toda a instrução 6502 definida em um espaço realmente pequeno, porque realmente não há muito.

Se você pode desenterrar uma ROM da Apple II, você pode simplesmente cortar e colar a partir daí ...

O 6502 possui modos de endereçamento diferentes, a mesma instrução possui vários códigos diferentes, dependendo do modo de endereçamento. Dê uma olhada nos links a seguir que descreve as diferentes maneiras pelas quais um 6502 pode recuperar dados da memória ou diretamente fora da ROM.

http://obelisk.me.uk/6502/addressing.html#imm

Isso é melhor - 6502 Conjunto de instruções Matrix:

https://www.masswerk.at/6502/6502_instruction_set.html

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top