kholdfuzion / rustendo64

Livecoding a Nintendo 64 emulator in Rust :D

rustendo64

Livecoding a Nintendo 64 emulator in Rust :D

Follow along

The entire process is currently being streamed on Twitch, and each segment is being recorded and uploaded to this YouTube playlist. For stream times and announcements, you can check out my Twitter.

At the end of each episode, I mark the latest commit with a tag so you can see where we finished. Check the releases for this repo to see those.

Helpful tools

• Hex Fiend
• Online disassembler
• Dash (OS X / iOS) for documentation. Compatible alternatives for other platforms can be found linked from Dash Docset Links.

Literature

• n64dev repo doc's
• VR4300 datasheet
• Forum post where we found some boot info
• Detailed N64 memory map
• Alternate MIPS register names

Test ROM's

• Turtle's enormous public domain ROM repository
• Pouet list
• Zophar
• PDROMs
• Micro-64
• PeterLemon's ROMs

License

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution (please read before submitting a PR!)

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

I do accept (and appreciate!) pull requests, but please, try to keep them to small, meaningful, isolated changes only that I can go over completely on the stream. Significant outside contributions, as cool as they may be, somewhat defeat the most important part of this project - documenting everything through livecoding. I'm happy to accept small cosmetic changes/bugfixes, but please, consider what the larger audience as a whole might be missing out on when they don't get to see the thought process and resources that went into making the contribution (which is unfortunately what happens whenever I accept a PR).

If you'd like to see a particular library or coding style used somewhere, opening an issue is much preferred over a PR, so we can discuss it beforehand and implement it live. This also keeps people from stepping on each others' toes and implementing the same things (yes, this has happened already).

Issues, especially pertaining to accuracy/bugfixes, are always more than welcome!