Hi, I need tabulated data for 6502 instructions which has the opcode, its byte length, the cycles spent, and the cycles spent if a branch is taken or if a page boundary is crossed.
I know this info is available widely, but I need it in tabulated form so I can directly make it into an array initialization for my emulator without having to manually type it in.
It may be in a website or in an emulator source code, I would appreciate if someone could point me to where I can find it.
If not, I'm going to type it and make it available here in case anybody needs it.
Also, is the instruction set described on this page accurate for NES's processor? http://www.obelisk.demon.co.uk/6502/instructions.html
It says it's from the BBC micro, but it's the 6502 processor, I assume it's the exact same processor used in the NES, right? I mean it's not a variation like 6510 or 65C02.
Thanks!
Tabulated data of 6502 opcodes, byte length and cycles ?
Moderator: Moderators
try any of the fceu source code, its in x6502.cpp, it has the cycle length of an instruction, though not the opcode length, i dont know any emu that actually uses a table for it, they just split it up into addressing modes. Though nintendulator has an addressing mode table for each opcode, that should help you generate the opcode length table faster.
- cpow
- NESICIDE developer
- Posts: 1099
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Here. The table starts on line 139. I believe it is correct and contains all undocumented and illegal opcodes.
I didn't find much use in organizing it by opcode/addressing mode. My assembler could perhaps be a bit faster once it finds an opcode if it only had to search through the addressing modes in another dimension from the opcode index. But I like the 1-d approach.
Undocumented opcodes may not be named exactly as you would expect...there's quite a few different opinions on the appropriate names for these opcodes.
I didn't find much use in organizing it by opcode/addressing mode. My assembler could perhaps be a bit faster once it finds an opcode if it only had to search through the addressing modes in another dimension from the opcode index. But I like the 1-d approach.
Undocumented opcodes may not be named exactly as you would expect...there's quite a few different opinions on the appropriate names for these opcodes.