bryanperris / cor64 Goto Github PK

N64 Emulator written in C#

License: MIT License

C# 92.89% C++ 6.02% Assembly 0.75% Batchfile 0.01% PowerShell 0.15% Shell 0.18% Python 0.01%

emulation c-sharp n64 mips emulator mips-assembler mips-assembly skiasharp testing unit-testing interpreter recompilation msil-compiler nintendo64 glfw3 dotnet dotnetcore dotnet-core

cor64's Introduction

cor64

C# based N64 Emulator

This is a work-in-progress freetime project

Debugging

When hex dumping a rom, the program code (after the IPL) always starts 0x1000 in the file normally

Development

What you need

.NET Framework / Mono
.NET Core 3.x or higher
For Linux: GLFW devel libraries

Required Global DotNet Tools

Paket
nuke.globaltool

Build and Run $ nuke Run

Run Unit Tests $ nuke Test [--filter ] [--debug-test]

CppSharp support for Ubuntu 18.04

Must have dotnet runtime 3.1 insalled

git clone https://github.com/InteropAlliance/premake-core/
cd premake-core
make -f Bootstrap.mak linux
cd ..
git clone --recursive https://github.com/mono/CppSharp.git
cd CppSharp
git checkout 1.0.1
cd build
cp -r ../../premake-core/bin/release/* premake/
./build.sh clone_llvm
./build.sh build_llvm
./build.sh package_llvm
./build.sh generate -configuration Release -platform x64
./build.sh -configuration Release -platform x64

GlideN64 Crashing

Make sure font file /usr/share/fonts/truetype/freefont/FreeSans.ttf exists

Now add the generated library to your ld configuration or use LD_LIBRARY_PATH

References

byuu's Bass Assembler: https://github.com/ARM9/bass
N64 Test Roms: https://github.com/PeterLemon/N64
Project64: https://github.com/project64/project64
cxd4 Rsp: https://github.com/cxd4/rsp
Mupen64: https://github.com/mupen64plus/mupen64plus-core
Cen64: https://github.com/n64dev/cen64
AngryLion RDP: https://github.com/ata4/angrylion-rdp-plus/releases

cor64's People

Contributors

Stargazers

Watchers

Forkers

msylvia

cor64's Issues

TensorFlow support

It would be interesting to use the C# TensorFlow wrapper library to teach AI on how to translate runtime MIPS code into something immediate such as LLVM-IR or MSIL, so that it can learn how to improve and optimize this task. Then for each unique program written for MIPS R4300I, all generated code paths can be cached into a database, then for future emulation, an entire rom can mostly rely on data from the database to help cut out most of the paths taken in the emulator itself. There could always be paths that have not been reached inside the ROM, so in those cases, the emulator will still need to be invoked to handle them. As for cases of self-modifying code, if they are predictable, then that code can be directly replaced with what it generates most of the time.

RDP Bugs

Alpha Compare Test: Results are 99% close, some few pixels are off
Combiner Overflow Test: Some things work and a lot are off
TextureCoordinates1 Test: Blue color in the lines are missing
TextureCoordinates2 Test: All colors are missing here
RDPTex0And1 Test: Some missing green 1s (middle rows), which I blame on alpha bugs but textures themselves look fine
CombinerLongTailConstants: Only the first RGBW gradient is broken
RSP DCT Tests (They involve the RDP): The issue with some of them is just related to timing. The test starts the RSP task after waiting for a certain number of RDP commands to be completed.

Switching the branch to main

TODO: Need to switch the default branch to main just as the millions of repos are doing so.

Investigate RDRAM size logic

The N64 hardware writes the probed RDRAM size into GPR S6, then its stored in a special spot of RDRAM known as "os_boot_config_t". Right now the emulator (and like others) injects the RDRAM size just before the CPU hits the entry point.

What I think the IPL may be doing is triggering the system to probe and dump the result into a register. If this is true, then it would be possible to make the emulator listen for this trigger and write in the value into s6. I could check more into depth on this issue, if I ever receive my N64drive.

VI Timing

If the CPU is running a lot slower than the VI, lots of issues happen in OS threading such as audio tasks preventing the game thread from doing much or if its too slow, there is a lot of thread idling.

RDP Pipeline and RDRAM

To create a discussion here.

Ref 1: project64/project64#574

RSP Integration

This is a tracker for incorporating the RSP into the emulator.

~~Implement MIPS 4000 instructions.~~
~~Handle halt/break commands~~
~~Support SP DMA~~
~~Implement the 128-bit vector unit (Cop2)~~
~~Pass basic RSP tests~~
~~Support the XBUS system for the RDP~~
07/07/2021: Major RSP fixes, other than some simple mistakes, load/store 'offset' operand requires clamping

FPU Integration

Here is a list of things done so far for the FPU:

C# Interpreter:

Load/Store: Complete
Add, Sub, Div, Mult: Passes Tests
Sqrt, Abs, Mov, Neg: Passes Tests
Round, Ceil, Floor, Truncate: Passes Tests
Convert: Passes Tests
Compare: Passes Tests
Mandelbrot: Passes Test
Exception Handling: Hard to directly handle in C# while being cross-platform agnostic

IL Recompiler: Everything works as expected like with the Interpreter, some of it does fallback to using the Interpreter to hand it.

FPU control/status: Partially implemented

FPU Rounding Support: round single/double results before each writeback

CFloat: A C# FPU interpreter class using C code to drive FPU operations. This will be an optional FPU interpreter backend that can be used to analyze FPU operations with more accuracy such as real exception handling, and round control.

For DotNetCode: Optionally use SIMD to perform float arithmetic, rounding, comparisons

TLB Support

It must be implemented as I hit something depending on it.

LLE RSP Yielding Issues

The CPU is allowed start a RSP task, then continue on without yield to the RSP first, that means depending on the core speeds between the processors for an emulator, there is nothing preventing DMEM race conditions.

A hack is working now for some RSP tests, having the CPU thread always sleep some when it attempts to unhalt the RSP but this solution won't work out well if the RSP gets really busy. Knowing that developers can write code on the real hardware and not have to do any yielding since the the clocks are assumed to never change so that means for LLE, without writing a cycle-accurate system, then yielding has to be forced in ways based on on how fast each Interpreter core executes. May need to generate a graphs on RSP usage patterns of common games.