At long last, two years and then some after starting this project, I have finished it. I can even play games on the Nintendo 64, albeit slowly. My github repository for this project has several useful files, however it is an absolute mess.

Here are the things that you might want that I have developed:

- Service files. I used SysV instead of systemd, because I decided to use DietPi to build my emulator, and it does not have a full systemd stack, I'm pretty sure. Regardless, when I started this I didn't know what systemd was, and since I know both systems, I stuck with SysV for this. The files are drag-and-droppable for any Linux system, it probably works on systemd too considering it's legacy support for SysV scripts. You'll need to change some configs in order to make them work, but it should be fairly simple, I tried to make them configurable.

- asplashscreen: Show a splashscreen over the bootup text. It just looks pretty.

- depends: fbi

- retrogame: Runs the GPIO-to-EV_KEY program in the background.

- depends: start-stop-daemon retrogame

- syncservice: automates rsync for updates, ie allowing the user to update the system without internet or a keyboard or opening the case.

- depends: rsync

I've learned a lot doing this. I am not a professional by any means, I'm just starting college now and in my winter break I have managed to finish this thing up, but I have definitely greatly advanced my understanding of many things by doing this. One of the things I think I should pass on is that if you are blazing a trail where there is little documentation, _you will have many difficulties_. It's not easy, even if you do know what you're doing. When something goes wrong, you are lost, as I have found myself time and time again.

Below are some of the tips I have collected, or at least the ones I recall.

- Don't be afraid of git. Use it to your advantage, it can be very handy. A `git log` can get you a lot of information you might not otherwise have. `git tag` allows you to see tagged releases, which could be useful for finding a last-stable branch, for example. You can `git checkout` a tag name.

- The bleeding edge helps sometimes. Just wait it out if you're having trouble, sometimes someone else will fix it later. Programs like these have maintainers for a reason: they know what they are doing. You can submit a patch if you're adventurous, just make sure it works first.

- Compile-time options. You can specifiy these yourself if the ones that are made by those configure scripts aren't good enough. I recommend `CFLAGS=-O3` at least, `-funroll-loops` isn't a bad idea either. There's plenty more that I've forgotten. Some cores require a platform which the configure scripts are bad at detecting on occasion. Try setting `platform=` to something, you can check the makefile for hints as to what it should be. I like `platform=rpi`, which works great for mupen64plus.

-`collect2...` Linker errors, probably. Check that you have all your libraries in place, and that the compiler knows where they are. If your platform isn't set, that could cause issues. Don't forget that you can specify extras at compile time too, either edit the makefile looking for `LIBS` or `LDFLAGS` or similar. Technically libraries can be added to `CFLAGS` at compile time instead of link time, but this is bad practice. Do it only if you have to.

That's all I've got for now. Good luck, and if you're making something like this and you don't want to follow the tutorials for RetroPie and the like, and you prefer a lighter, more optimized setup, I may be able to help you.