/AgNES

An NES compiler written from scratch

Primary LanguageC++MIT LicenseMIT

AgNES: A C-- NES compiler written from scratch

Created by Niko Savas and Vicky Bilbily as a project for McMaster's 4TB3 Compilers class

How to use

First you'll need a couple tools:

  1. An NES emulator. For testing, we used FCEUX.
  2. A 6502 assembler. We recommend WLA DX. Make sure that wla-6502 and wlalink are on your path.

The simplest way to start using AgNES is to check out the /example/ folder. NES files require custom headers and footers, which are provided as NES_HEADER.s and NES_FOOTER.s. By running build.sh, you will build a file named game.nes. This can be run with an emulator - the example game is a sprite moving across the screen. By changing example/input.c you can have the sprite move in different directions.

Compilation steps

Scanner

Input: C-- file as a string
Output: List of tokens (token.h)

Parser

Input: List of tokens
Output: Abstract syntax tree (astNode.h)

Semantic Analysis

Input: Abstract syntax tree
Output: Symbol table (symbolTable.h)

Intermediate Code (IR) generation

Input: Symbol table
Output: List of three address code (TAC) instructions (irGenerator.h)

Code Generation

Input: TAC list and symbol table
Output: 6502 Assembly file

Design challenges

6502 architecture only has 3 registers

This causes generated 6502 code to be much more verbose without optimizations. Not only are there only 3 registers, but many instructions only work with specific registers. For example, addition can only be performed against the Accumulator register. This is different from other instruction sets which have more freedom about where values can be loaded from and modified. While the scope of this project did not include optimizations, they could be added (in between the IR generation and code generation step) to significantly reduce the number of instructions generated by AgNES.

NES stack is tiny

The NES stack is a 256-byte array. This restriction can be somewhat limiting to recursion depth, as traditionally the stack would contain return addresses, register values, as well as local variables. To avoid this, we only use the native stack for JSR (Jump to Subroutine) and RTS (Return from subroutine). The rest of the information traditionally stored on the stack instead uses a custom stack implementation that uses the front of the NES main memory. This allows for much more recursion depth in the C-- applications.

The NES has special memory locations and functionality

The way that the NES handles sprites and refreshing the screen is not intuitive when the 6502 assembly code is abstracted away behind C--. To combat this, we included a number of custom tokens (macros) that can be found in token.h. While writing the C-- code, these tokens can be used and will be translated into the necessary 6502 assembly code for the functionality desired.

Future Development

Due to time constraints on this project, some features were left out. These include:

  • Boolean expressions
  • Function return values
  • Arrays