CAT | Programming
NES emulation is something that has been done and done again. At this point in time, there’s really no good reason to write a NES emulator other than to educate yourself; however, that’s exactly what I want to do.
I decided I wanted to learn more about how emulation works, so I started reading other people’s articles on emulation and their source code. In doing this, I noticed one consistent thing: these emulators were coded for speed and accuracy in emulation. Speed and accuracy are both wonderful things, but these jumbled messes of highly-optimized code strewn across poorly-documented files were hard for a beginner to understand. The way things are now, it’s quite hard for somebody with no prior knowledge or experience to jump right in to emulation, and I want to change that.
I am currently working on a NES emulator (it doesn’t have a name yet, but I’m sure it will be stupid). The main design goals behind this emulator are not speed and accuracy. Modern CPUs are fast enough to handle a very inefficient NES emulator, and accuracy (emulation of specific hardware quirks) can be added later as bug reports come in for different games. The purpose of this emulator is to be extremely readable and accessible to anyone with a good grasp of the C language. In my opinion, this means highly modular code (each hardware component should have its own .c file), no huge abstractions and macros to hide what work is really being done, and no cryptic-named files full of #defines or strange functions that don’t really belong anywhere.
Most importantly, I am going to document every function in every file. I want for somebody with a decent understanding of the NES hardware to be able to immediately understand what my program is doing and how.
This post has mostly been a note to myself of goals I need to keep sight of, but there will be real code to see shortly. As soon as I get the emulator in a somewhat-working state, I’ll upload the code and begin explaining EVERYTHING.
I wrote a little app to toggle the hiding/showing of hidden files in the OS X Finder, and I’m going to tell you about it. You can find it here (download link) or on my Projects page. The largest part of this application is the icon. The executable file itself is actually just a shell script, the entire source of which is as follows:
#!/bin/sh
if [ `defaults read com.apple.finder AppleShowAllFiles` = "false" ]; then
defaults write com.apple.finder AppleShowAllFiles true
else
defaults write com.apple.finder AppleShowAllFiles false
fi
osascript -e 'tell application "Finder" to quit'
# Finder often tries to open too quickly (causing weird problems)
# so I tell it to wait a second.
sleep 1
osascript -e 'tell application "Finder" to activate'
After seeing that, you might wonder how I got a stupid little shell script all packaged up so nicely in a .app. I’m running low on ideas to blog about, so I guess I’ll explain!
Basically, every OS X application bundle is really just a bunch of files thrown into a folder. The application you see is just a directory with “.app” appended to the end. To view the contents of an app, simply select it in Finder, click the gear in the toolbar, and select “Show Package Contents”. The two things needed to make an application run are the executable (which resides at MyAppName/Contents/MacOS/executablegoeshere) and an Info.plist file. The executable is the code that runs and the Info.plist just tells the OS what everything in the bundle is. If you open up the plist, you’ll see it’s basically an XML document telling the OS what my executable is called, what the icon is called, and giving my app a unique identifier (com.dylanedwards.houdinifile).
I started Project Euler over the Summer and totally forgot about it. The other day I started playing around with ideas of writing a library for integer math with arbitrarily-large numbers in C. As I started writing code, I remember a Project Euler problem (number 13) involving the sum of 100 50-digit numbers that I wanted to solve, so I got some basic arithmetic operations coded and solved it (woohoo, source is now on my Project Euler page).
Anyway, the point of this post is that I wanted to share the code with you. It’s now available here (download link) (moved to http://big-integers.googlecode.com) or on my Projects page. It’s very basic and doesn’t currently support division, comparison, or negative numbers. All of those things (and more!) are coming soon, but I just thought I’d post what I have done. I’ll probably keep updating it (and I’ll post to let you know) over the next week or so.
The algorithms for the three operations that it supports (addition, subtraction, multiplication) are all built off of the basic concepts that we all learned in elementary school. They’re all very simple (the multiplication looks a little confusing at first), and work exactly as if you were solving a problem on paper.
Enjoy!
PS. You can adjust the size (number of digits) of the bignum type in bn.h.
