gianlucag/mos6502

A fast & simple MOS 6502 CPU emulator written in C++

MOS6502 Emulator in C++

This is my C++ implementation of the MOS Technology 6502 CPU. The code is written to be more readable than fast, however some minor tricks have been introduced to greatly reduce the overall execution time.

main features:

• 100% coverage of legal opcodes
• decimal mode implemented
• read/write bus callback
• jump table opcode selection

still to implement

• 100% cycle accuracy
• illegal opcodes
• hardware glitches, the known ones of course :-)

The emulator was extensively tested against this test suite:

https://github.com/Klaus2m5/6502_65C02_functional_tests

and in parallel emulation with Fake6502 http://rubbermallet.org/fake6502.c

so expect nearly 100% compliance with the real deal... at least on the normal behavior: as I said stuff like illegal opcodes or hardware glitches are currently not implemented.

Why yet another 6502 emulator?

Just for fun :). This CPU (and its many derivatives) powered machines such as:

• Apple II
• Nintendo Entertainment system (NES)
• Atari 2600
• Commodore PET and VIC-20
• Commodore 64 (6510 chip actually, but fully compatible emulator-wise)
• BBC Micro

and many other embedded devices still used today. You can use this emulator in your machine emulator project. However cycle accuracy is not yet implemented so mid-frame register update tricks cannot be reliably emulated.

Some things emulators: emulator types

You can group all the CPU emulators out there in 4 main categories:

• switch-case based
• jump-table based
• PLA or microcode emulation based
• graph based

The latter are the most accurate as they emulate the connections between transistors inside the die of the CPU. They emulate even the unwanted glitches, known and still unknown. However, the complexity of such emulators is non-linear with the number of transistors: in other word, you don't want to emulate a modern Intel quad core using this approach!!!

for an example check this out: http://visual6502.org/JSSim/index.html

The PLA/microcode based are the best as they offer both speed and limited complexity. The switch-case based are the simpler ones but also the slowest: the opcode value is thrown inside a huge switch case which selects the code snippet to execute; compilers can optimize switch case to reach near O(log(n)) complexity but they hardly do it when dealing with sparse integers (like most of the CPU opcode tables).

Emulator features

My project is a simple jump-table based emulator: the actual value of the opcode (let's say 0x80) is used to address a function pointer table, each entry of such table is a C++ function which emulates the behavior of the corresponding real instruction.

All the 13 addressing modes are emulated:

// addressing modes
uint16_t Addr_ACC(); // ACCUMULATOR
uint16_t Addr_IMM(); // IMMEDIATE
uint16_t Addr_ABS(); // ABSOLUTE
uint16_t Addr_ZER(); // ZERO PAGE
uint16_t Addr_ZEX(); // INDEXED-X ZERO PAGE
uint16_t Addr_ZEY(); // INDEXED-Y ZERO PAGE
uint16_t Addr_ABX(); // INDEXED-X ABSOLUTE
uint16_t Addr_ABY(); // INDEXED-Y ABSOLUTE
uint16_t Addr_IMP(); // IMPLIED
uint16_t Addr_REL(); // RELATIVE
uint16_t Addr_INX(); // INDEXED-X INDIRECT
uint16_t Addr_INY(); // INDEXED-Y INDIRECT
uint16_t Addr_ABI(); // ABSOLUTE INDIRECT

All the 151 opcodes are emulated. Since the 6502 CPU uses 8 bit to encode the opcode value it also has a lot of "illegal opcodes" (i.e. opcode values other than the designed 151). Such opcodes perform weird operations, write multiple registers at the same time, sometimes are the combination of two or more "valid" opcodes. Such illegals were used to enforce software copy protection or to discover the exact CPU type.

The illegals are not supported yet, so instead a simple NOP is executed.

Inner main loop

It's a classic fetch-decode-execute loop:

while(start + n > cycles && !illegalOpcode)
{
	// fetch
	opcode = Read(pc++);

	// decode
	instr = InstrTable[opcode];

	// execute
	Exec(instr);
}

The next instruction (the opcode value) is retrieved from memory. Then it's decoded (i.e. the opcode is used to address the instruction table) and the resulting code block is executed.

Public methods

The emulator comes as a single C++ class with five public methods:

mos6502(BusRead r, BusWrite w);
void NMI();
void IRQ();
void Reset();
void Run(uint32_t n);

mos6502(BusRead r, BusWrite w);

it's the class constructor. It requires you to pass two external functions:

uint8_t MemoryRead(uint16_t address);
void MemoryWrite(uint16_t address, uint8_t value);

respectively to read/write from/to a memory location (16 bit address, 8 bit value). In such functions you can define your address decoding logic (if any) to address memory mapped I/O, external virtual devices and such.

void NMI();

triggers a Non-Mascherable Interrupt request, as done by the external pin of the real chip

void IRQ();

triggers an Interrupt ReQuest, as done by the external pin of the real chip

void Reset();

performs an hardware reset, as done by the external pin of the real chip

void Run(uint32_t n);

It runs the CPU for the next 'n' machine instructions.

Links

Some useful stuff I used...

http://en.wikipedia.org/wiki/MOS_Technology_6502

http://www.6502.org/documents/datasheets/mos/

http://www.mdawson.net/vic20chrome/cpu/mos_6500_mpu_preliminary_may_1976.pdf

http://rubbermallet.org/fake6502.c

mos6502's Issues

The reset vector is read in reverse order

A real chip, and Mike Chambers' fake6502 as well, read the reset vector low byte first (i.e. $fffc) and then $fffd. But it seems like this emulator does it in reverse order.

I appreciate it's a tiny thing but it's showing as a difference in my test suite

What do we think? Do we care about such tiny differences?

access to uninitialized status bits

The "status" member has uninitialized bits. When I noticed that a static instance of mos6502 would work as expected but one on the stack or heap would show subtle differences in program execution (static data=bss), it pointed me to the bug.

Otherwise, this is a very nice and efficient piece of code. Using it for my second project. I love it!

Question, not an issue

Would it be technically possible to use this to access a graphical config menu thats present on a sidkick pico? I use your sidberry to play sids via the sidkick pico and want to tune some stuff thats in the config menu.

Misleading README suggests that Commodore 64 used, 6502.

The README suggests the C64 used the 6502, but actually, it used the 6510, is this a 6502 emulation or 6510? It suggests you could make a C64 with this emulation, but if it is a 6502 emulator, it may or may not work.

The README seems out-of-date

There is reference to the Run method, but it doesn't match the code.

The README says void Run(uint32_t n); but the code says void Run(int32_t cycles, uint64_t& cycleCount, CycleMethod cycleMethod = CYCLE_COUNT);.

The header file doesn't have guards

This causes include loops when used as a part of larger projects

The dummy read before stack pulls doesn't seem to happen

The stack pointer hardware in the 6502 can only update the stack pointer after the stack access has happened. So, it decrements the stack pointer after pushing a value onto the stack, so that the stack pointer is ready for another push.

But when pulling, this means it has to pull some dummy data (just to update the stack pointer) before pulling the real data.

It looks as though gianlucag/mos6502 does not do this dummy read. While executing a plp instruction, which is a four-cycle instruction, gianlucag/mos6502 performs only two memory reads:

1. the opcode byte
2. the PSW from the stack

but the real chip will perform the following four memory reads:

1. the opcode byte
2. the next byte in the instruction stream (all instructions do this in cycle two, while the instruction is being decoded, just in case)
3. the byte immediately below where the PSW is about to be read from
4. the PSW from the stack

Exactly the same problem affects other instructions that read from the stack: rts, pla, and probably also rti.

Please add a license

I've converted your code to Delphi but you're missing a license. Thank you