A sub–cycle-accurate Nintendo Entertainment System emulator.
Shawn (L. Spiro) Wilcoxen
A Nintendo Entertainment System emulator with the goal of being fully “sub–cycle-accurate”; the work is correctly divided across the individual cycles for each instruction and cycles are divided into φ1 and φ2.
YouTube Video: Castlevania Demo Play (Low Noise)
YouTube Video: Battletoads Opening (Extreme Noise)
YouTube Video: Akira Opening (Extreme Noise)
NTSC-CRT library: https://github.com/LMP88959/NTSC-CRT
We are aiming for “Sub-Cycle Accuracy”: https://emulation.gametechwiki.com/index.php/Emulation_accuracy#Subcycle_accuracy
This means that multi-byte writes are correctly partitioned across cycles and partial data updates are possible, allowing for the more esoteric features of the system to be accurately emulated. This means we should be able to support interrupt hijacking and any other cases that rely heavily on the cycle timing of the system.
Additional options/features to facilitate accurate emulation:
- Start-Up: Start from known state or from random state. Helps the random seed in some games.
- Hardware bugs will be emulated in both their buggy and fixed states (OAMADDR bugs (writing fewer than 8 bytes on the 2C02G) are examples of this).
- Unofficial opcodes used by games will be optionally supported.
- The bus will be open and correctly maintain the last floating read.
- Etc.
If behavior differes from the actual hardware result, it is considered a bug. Hacks are to be avoided as much as possible.
The CPU should be completely sub–cycle-accurate, as every individual cycle is documented there. The same should apply to the PPU (questions surround PAL differences at the cycle level) and the APU.
Timing is not based off audio or monitor refresh rates as is done in many emulators. We use a real clock (with at-minimum microsecond accuracy) and match real timings to real time units, which we can speed up and slow down as options. The NTSC version’s CPU will need to pump out ~29,780.506887 cycles per frame at 60.098814 FPS, while the PAL will need to pump out ~33,247.485977 cycles at 50.006979 FPS. This means there is no noticeable visual delay (rendered frames are presented essentially immediately, rather than waiting for a monitor refresh, doing a frame’s worth of work, and then providing the visible frame after a delay) and that input is polled with exactly the same timing as in a real console, eliminating all input lag. It should both look and feel like a real console, with responsive controls that feel identical to how they do on real machines.
There were initially some concerns that being sub–cycle-accurate would mean extra overhead—other emulators may skip useless redundant opcode fetches, but not here, and each fetch is accompanied by an entire CPU tick and all the work that goes into updating the CPU state, etc. For this reason, most systems were implemented in an entirely branchless fashion—there are no “if”/“else” statements, “%” operations, “&” operations, “>=”/“<” checks, etc. when accessing memory; address mirroring, address mapping to registers, etc., is all handled entirely without branching, and most CPU, PPU, and APU cycles are branchless as well. This more-than made up for the cycle-accuracy overhead.
Other features will include:
- A debugger.
- A disassembler.
- An assembler.
- 1-877-Tools-4-TAS.
-
- Stepping and keylogging.
-
- Movie-making.