airloaf/v6502

6502 C++ Library

V6502

MOS 6502 CPU library emulator written in C++

Features

• Instruction Accurate Implementation
• Modifiable Memory Bus (Useful for systems that utilize bank switching and memory mapped I/O)
• Simple To Use API
• No dependencies for the 6502 Library

Dependencies

Required:

• CMake 3.9+

Note: Older versions of CMake may work, but 3.9 is what I have been using while developing V6502

Optional:

• Boost 1.66+ # Only need headers for Boost. Boost is only used for the unit tests.

You will need to modify the CMakeLists.txt file with the appropriate paths to find Boost. There are two variables in the CMakeLists.txt file INCLUDE_DIR and LIB_DIR. By default they point to C:/DevelopmentLibraries/include/ and C:/DevelopmentLibraries/lib/x64/ respectively. Ensure you have these directories created or specify the correct path in your environment which has the Boost library installed.

Note: Older versions of Boost may work, but 1.66+ has been tested to work.

Building

There are two build targets for CMake, the actual V6502 library and the unit tests.

Compiling V6502

By default V6502 will compile into a static library, but this can be changed in CMakeLists.txt. Modify LIB_TYPE to be SHARED for a dynamic library. Keeping it STATIC will make it a static library

Compiling Unit Tests

The unit tests require the boost library, see Dependencies. The unit tests compile alongside the main library, so no extra steps are needed. You will see an executable called Tests which can be run in a terminal.

Use Cases

The main purpose of this library is to provide a portable software implementation of the 6502 cpu for the development of emulators. My initial intention was to use this library to aid in the development of an NES emulator I hope to complete some day. The 6502 has been used in many devices such as:

• Apple I and II
• Atari 2600/5200/7800
• Commodore 64/128
• Nintendo Entertainment System and Famicom
• TurboGrafx-16

If someone desires to create an emulator for any of the aforementioned devices, they will need an implementation of the 6502 cpu. This library should work perfectly for this type of application.

This library does not necessarily need to be used in the development of an emulator, it can be used for other non-gaming applications:

• 6502 Interpreters
• CPU Visualizer
• Virtual Machine for a 6502 computer

References

List of articles, datasheets and videos used in the development of this library

• Rockwell R650X and R651X Microprocessors Datasheet
• Obelisk CPU Instruction Reference
• NES Dev Wiki
• NES Dev CPU Cycles

v6502's Issues

Pipelined instructions

The 6502 performs some form of pipe lining. The first cycle of each instruction (getting the actual opcode of the instruction) occurs at the last cycle of the previous instruction. This is also why crossing page boundaries on some instructions causes an extra cycle to be thrown. See the cycle information for each instruction here

NesDev CPU Tests

On the NesDev wiki, there are many CPU tests which can test the correctness of our CPU. CPU Tests

Requirements:

• Implement test to check for NesTest.nes by kevtris
• Implement test to check for nstr_test_v5 by blargg

Use PDCurses for CPU monitor for Windows

PDCurses is a OpenCurses implementation for windows. We should look into this for implementing the CPU monitor for windows based platforms.
PDCurses

Remove get and set register file functions and replace with a single one

Instead of having a separate getter and setter for the register file, we should instead have a single register file function which returns a reference to it. This will allow modification and reading of the register file in one function.

Cycle Accurate Implementation

Currently we are only Instruction accurate since we are not modifying the registers and memory correctly per cycle. NES Dev wiki has a page on the CPU cycle details that should help in making a cycle accurate emulation of the 6502 processor. Cycle Details.

Change Address Bus to Memory Bus

The name Address Bus should be changed to Memory Bus. According to the datasheet, you write addresses to the address bus and then read the data for that corresponding address in the data bus. Memory Bus is a more suitable name since it both reads and writes into memory.

Unit Test Instructions Individually

The current tests for V6502 are difficult to write. They involve writing certain values into memory. We should unit test the instructions individually. In order to do so, we will need to extract each function and have the bare necessaries required to execute each individual instruction.

Support for Unofficial Opcodes

If we look at the op code table we have defined, there are many gaps. These gaps represent unofficial opcodes. While they were not intended to be used as instructions, an actual 6502 cpu can still process it as an instruction.

NESDev Unofficial opcodes This site right here has a list of unofficial opcodes. It even details some NES games which utilize such opcodes. For a true NES emulator these would have to be implemented into the 6502 CPU library.

Remove Default case in instruction tick

The default case for this switch statement should never be called on, but it is required for successful execution of the processor. We need to figure out why this is the case and remove it.

CPU Monitor

In order to run programs and ensure correctness of the CPU, a CPU monitor should be implemented.

Requirements:

• View all CPU registers
• View current location in memory (program counter)
• Print current instruction

Doxygen Documentation

Doxygen can create some good looking documentation web pages. This should be used when uploading a web format of the API.

Implement Decimal Mode Instructions

ADC and SBC with decimal mode has not been implemented. Decimal mode article

Tests and implementation for interrupts

We currently do not have tests for interrupts (BRK, NMI and IRQ).

We should test for the following scenarios

• IRQ during a BRK
• NMI during a BRK
• Properly returning from an interrupt
• IRQ when the I flag is set

Remove allocations for addressing modes and instructions

The CPU is very sluggish when running it on VNES. I can imagine it has to do with all the allocations that come into play when creating a new instruction as well as addressing modes. I think the best move will be to move the addressing mode functionality within the instruction class and we should only allocate a single instruction object and re-use it constantly. This should improve the CPU's performance greatly.