views:

1104

answers:

6
+6  Q: 

6502 CPU Emulation

Its the weekend, so I relax from spending all week programming by writing a hobby project.

I wrote the framework of a MOS 6502 CPU emulator yesterday, the registers, stack, memory and all the opcodes are implemented. (Link to source below)

I can manually run a series of operations in the debugger I wrote, but I'd like to load a NES rom and just point the program counter at its instructions, I figured that this would be the fastest way to find flawed opcodes.

I wrote a quick NES rom loader and loaded the ROM banks into the CPU memory.

The problem is that I don't know how the opcodes are encoded. I know that the opcodes themselves follow a pattern of one byte per opcode that uniquely identifies the opcode,

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

etc

However I'm not sure where I'm supposed to find the opcode argument. Is it the the byte directly following? In absolute memory, I suppose it might not be a byte but a short.

Is anyone familiar with this CPU's memory model?

EDIT: I realize that this is probably shot in the dark, but I was hoping there were some oldschool Apple and Commodore hackers lurking here.

EDIT: Thanks for your help everyone. After I implemented the proper changes to align each operation the CPU can load and run Mario Brothers. It doesn't do anything but loop waiting for Start, but its a good sign :)

I uploaded the source:

http://www.codeplex.com/Cpu6502/SourceControl/DirectoryView.aspx?SourcePath=&changeSetId=1810

If anyone has ever wondered how an emulator works, its pretty easy to follow. Not optimized in the least, but then again, I'm emulating a CPU that runs at 2mhz on a 2.4ghz machine :)

+1  A: 

This book might help: http://www.atariarchives.org/mlb/

Also, try examing any other 6502 aseembler/simulator/debugger out there to see how Assembly gets coded as Machine Language.

Brendan Kidwell
+8  A: 

The opcode takes one byte, and the operands are in the following bytes. Check out the byte size column here, for instance.

moonshadow
So, I'll have to modify each opcode so it knows how far to look ahead from the PC to get its arguments?
FlySwat
You'll have to keep a table somewhere, yeah. Though it'll never be more than three bytes. Or just hardwire it in the code that does each instruction's work.
moonshadow
I actually have that book.
Brad Gilbert
+3  A: 

If you look into references like http://www.atarimax.com/jindroush.atari.org/aopc.html, you will see that each opcode has an encoding specified as:

HEX LEN TIM

The HEX is your 1-byte opcode. Immediately following it is LEN bytes of its argument. Consult the reference to see what those arguments are. The TIM data is important for emulators - it is the number of clock cycles this instruction takes to execute. You will need this to get your timing correct.

These values (LEN, TIM) are not encoded in the opcode itself. You need to store this data in your program loader/executer. It's just a big lookup table. Or you can define a mini-language to encode the data and reader.

Frank Krueger
I don't think the LEN and TIM are actually encoded in, I think you have to provide that. I already did that with the timing, each opcode is aware of how many cycles its "supposed" to take.
FlySwat
They actually are in many cases. For all the opcodes with an argument bits [4:2] of the opcode define a 3 bit encoding of the addressing mode. I've found it to be consistent:0=INDIRECT X, 1=ZERO PAGE, 2=IMMEDIATE (sometimes ACCUMULATOR), 3=ABSOLUTE, 4=INDIRECT Y, 5=ZERO PAGE X, 6=ABSOLUTE Y, 7=ABSOLUTE X
Mark Renouf
+1  A: 

The 6502 manuals are on the Web, at various history sites. The KIM-1 shipped with them. Maybe more in them than you need to know.

gbarry
+1  A: 

Wow, I coded some assembly code for my Commodore CBM 4016 (16 was the memory size... in KB!) and my good old Apple //e.
But it was some... say... 25 years ago, so I fear my memory has faded.
But I appreciated the walk down the memory lane! ;-)
Good luck with your search! :-D

PhiLho
A: 

The apple II roms included a dissassembler, I think that's what it was called, and it would show you in a nice format the hex opcodes and the 3 character opcode and the operands.

So given how little memory was available, they managed to shove in the operand byte count (always 0, 1 or 2) the 3 character opcode for the entire 6502 instruction set into a really small space, because there's really not that much of it.

If you can dig up an apple II rom, you can just cut and paste from there...

stu