Tabulated data of 6502 opcodes, byte length and cycles ?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Tabulated data of 6502 opcodes, byte length and cycles ?

Post by Petruza » Sat Mar 13, 2010 11:37 am

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!

qeed
Posts: 61
Joined: Tue Jun 17, 2008 11:51 am

Post by qeed » Sat Mar 13, 2010 11:41 am

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.

User avatar
cpow
NESICIDE developer
Posts: 1099
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Sun Mar 21, 2010 10:48 am

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.

Post Reply