Getting Started

This chapter will provide you with information to help you get a smooth start to the project.

Gitlab

Each group has been provided with a Gitlab repository. You cannot push directly to the master branch. Instead, make proper use of branches and merge requests.

Template project

Each group will get a template project. A mostly empty project with some defaults filled in. It already has some required dependencies set up, and quite importantly sets the optimization level to 1. The default optimization level of 0 is too slow to both run the emulator and ppu in real time. You can the --release cargo flag for even more optimizations.

Tasks

Creating the emulator is quite a big project. It may be hard to find a good starting point. Therefore, here are a few hints for things you can do first.

get_cpu

First, make a start at implementing the get_cpu function on the TestableCpu trait. This function is called by the testing framework, gives you a rom and expects a new cpu object (or an error).

Rom parsing

To build a cpu, you need to parse the binary data in the rom that is supplied. It is recommended that you start with a simple ROM mapper like NROM. The ROM will follow the iNES file format. You can find more links and information about the format(s) on the links page.

Instruction Parsing and Executing

The rom contains information about the instructions to run, the graphics for the PPU, and which mapper to use (you can read up on what a mapper is here)

The instructions are stored in so-called PRG-ROM (program rom), while graphics data is found in CHR-ROM (character rom).

The CPU cannot directly access CHR-ROM, only the PPU can. Similarly, the PPU cannot access PRG-ROM. Only the cpu can. Since we implemented the PPU for you, dealing with it is quite simple. But you are responsible for implementing the CPU.

PRG-ROM contains CPU instructions. These are encoded as one or more bytes, and to execute them they need to be parsed.

The first instruction to execute is located at a certain address in memory. This exact address is stored in memory too, but always at the same place. This place is called the reset vector which located at 0xfffd and 0xfffc on the 6502.

Further Steps

After implementing parsing and (some) executing of instructions you can start with the CPU's tick function. This is called once every 3 pixels that are drawn on the screen by the PPU. This is the same ratio as the real NES used.

Once you can run some instructions, you could start looking at things like interrupt handling, correct startup state and more and some of the bonuses. You can also run some of the more advanced tests from the testing framework.