
I made an NES emulator – What I learned about the original Nintendo - fogleman
https://medium.com/@fogleman/i-made-an-nes-emulator-here-s-what-i-learned-about-the-original-nintendo-2e078c9b28fe
======
coldpie
If you're into this kind of thing, just dig in and give it a shot! Old systems
are surprisingly understandable after a few hours' research and fooling
around.

There's a community that looks for unused content that remains in games. The
main wiki for this community is <[http://tcrf.net/](http://tcrf.net/) >, which
contains a fascinating amount of material. If you don't see your favorite old
game on there, why not dissect it and try to find some unused stuff?

I did this for a favorite old game of mine called M.C. Kids. I reverse-
engineered the game's level and graphics data formats and managed to create a
level dumper for the game. Then, I did the same for a leaked prototype version
of the game. I took the dumped images and made a page on TCRF comparing them:

[http://tcrf.net/Proto:M.C._Kids](http://tcrf.net/Proto:M.C._Kids)

It took a few months on afternoons and weekends. It was very challenging, but
I never felt overwhelmed by the details. There's really only so much you can
do with three registers and little more than adding and branching
instructions. If you're curious to see what a reverse-engineered level dumper
looks like, the code is available at
<[https://gitlab.com/mcmapper/mcmapper/blob/master/main.c](https://gitlab.com/mcmapper/mcmapper/blob/master/main.c)
>.

~~~
fit2rule
>Old systems are surprisingly understandable after a few hours' research and
fooling around.

This is why I say old computers never die - their owners do! Old systems have
lots of technology to engage the hacker mind.

By the way, my favourite emulator is Oriculator, which emulates the
Oric-1/Atmos/Telestrat/Pravetz 8-bit machines that never had much of a chance
in the 80's .. just look at this beautiful code, for example, of how to
emulate a 6502:

[https://code.google.com/p/oriculator/source/browse/trunk/650...](https://code.google.com/p/oriculator/source/browse/trunk/6502.c)

With the revival of emulation of these systems, we're even getting new
software written for them - in the modern era, titles are being released for
these old machines that we would _never_ have though possible in the 80's.
Just look at this beautiful collection for the Oric-1 - all made in the 21st
Century - for example:

[http://space1999.defence-force.org/](http://space1999.defence-force.org/)

[http://stormlord.defence-force.org/](http://stormlord.defence-force.org/)

[http://1337.defence-force.org/](http://1337.defence-force.org/)

[http://im.defence-force.org/](http://im.defence-force.org/)

[http://skooldaze.defence-force.org/](http://skooldaze.defence-force.org/)

[http://oricium.defence-force.org/](http://oricium.defence-force.org/)

Featuring Gameplay and Graphics that we would _never_ have thought possible in
the 80's!

[http://www.oric.org/software/pulsoids-1515.html](http://www.oric.org/software/pulsoids-1515.html)

Check out this collection from Twilighte, who before his untimely departure
was a real master of this platform in the 21st century:

[http://www.oric.org/index.php?page=software&fille=softwarese...](http://www.oric.org/index.php?page=software&fille=softwaresearch)

So much fun to be had on these old machines!

~~~
henrikschroder
I wonder why it's possible to get "better" programs for old hardware now.

Is it because the field of CS has advanced further, which means that we can
apply modern ideas and algorithms?

Or is it because we can cheat and have a toolchain running on vastly superior
hardware, which enables us to use it in ways that would have been too time-
consuming to develop back in the day?

~~~
throwawayspeccy
I don't think fancy algorithms and data structures are common or particularly
useful in retrocomputing. I think it's primarily because programs were written
back then under strict time and financial constraints, whereas now
retroprograms and homebrew are written as hobbies, with the lack of deadlines
and abundance of passion that entails.

~~~
fit2rule
I don't know about that - I've been following the Oric scene for a while and
my perception is that there are indeed old programmers returning to the
systems of their youth with renewed vigour, but also a better understanding
for how to organize their project - and sources - in a way that makes more
sense. 30 years of optimizing code does tend to turn you into a better
developer, and when you return - for no reason other than the pure joy of it -
to these old systems, often things are done in unique ways. Twilighte found a
new video mode for the Oric-1 which inspired him to write games that were a
bit more modern in their sense of quality and playability - I think the
machines that came after the Oric inspired him quite a bit.

It also helps that the toolchains are far superior to what we used to have ..
I never would have thought, in my youth, that I'd be writing C code for the
Oric-1, but indeed the OSDK has a C compiler that makes the effort of packing
code into 48k a lot more fun than it used to be!

But in the end, you don't write software for these old machines unless you
have a lot of passion, and that's what counts, I think. There is a lot of
passion for the Oric-1 these days, that is for sure .. at least in the small
scene that keeps the machines alive.

~~~
throwawayspeccy
You're right, decades of experience are also very important (though there are
youngsters starting on platforms like the NES or TI graphing calculators doing
cool stuff as well).

I'm not sure I agree about toolchains, though. The 6502 is not a very good
target for C compilation, pretty much any assembly programmer can code circles
around what cc65 produces. So, no offense to you or anyone else that writes C
for 8-bit machines, but I don't think any of the new games and programs that
really "push the limits" of these machines are written in C. So that leaves
modern cross assemblers, which are indeed much more capable than common
target/native assemblers of the olden days, but don't exactly afford a quantum
leap of productivity either.

Then again, modern emulators are a godsend for debugging.

~~~
fit2rule
>>Then again, modern emulators are a godsend for debugging.

Hell yeah they are. I think thats also a key factor for why development on the
old machines is experiencing a revival.

------
Scuds
Watching the sprites in vram while the game runs is really neat, and shows a
bit about how the game is put together. For instance in Kirby's Adventure,
(IIRC)Kirby's walking sprites take up about half the available RAM, and they
get swapped out for the flying sprites when he jumps.

Compare this to some of the early non bank switched games where the all
sprites fit entirely in memory, with some creative tweaks (bushes are
recolored clouds, etc).

It's a bit myopic of Nintendo that on-cartridge mappers had to be necessary,
but on the other hand, it's early 80's consumer hardware; it was probably
state of the art in the late 70's ... which makes it hilarious that Wario's
Woods was released in 1994.

~~~
brandons
I wouldn’t call it “myopic,” if anything it was forward-thinking...the cost of
memory in the early 80s was high enough that including more than the 2 KB of
built-in RAM might have made the Famicom/NES way too expensive. They designed
the machine with internals that could be extended with extra memory and
additional chips inside the _cartridges_ , so that over the ~15-year lifespan
of the NES as technology advanced and the cost of memory dropped, the
cartridges enabled ever more powerful, impressive games, but stayed about the
same price ($40 iirc) the whole time.

~~~
agumonkey
And in those days, any amount of additional RAM had huge impacts on games
(then sales).

------
fsniper
The source code is really clean and easily comprehensible. I really liked how
you handled cpu frequency with console stepping on gl updates.

------
icesoldier
Related to this is Lizard, a Kickstarter project that got funded last year,
where one person is writing a new game for the NES. He's posted some
development blogs as updates to the project, and it's fascinating reading
about the design considerations he's taken:

[https://www.kickstarter.com/projects/1101008925/lizard/updat...](https://www.kickstarter.com/projects/1101008925/lizard/updates)

(Of note, this is the same one who made MOON8 - a cover project for Pink
Floyd's Dark Side of the Moon for the NES [0] - and more recently, getting the
"2A03 Puritans" album, a NES chiptune collaboration album, onto a rom and
cartridge [1].)

[0]
[http://rainwarrior.ca/music/moon8.html](http://rainwarrior.ca/music/moon8.html)

[1]
[http://rainwarrior.ca/projects/nes/2a03puritans.html](http://rainwarrior.ca/projects/nes/2a03puritans.html)

\---

I've personally only messed with the NES from an audio perspective, having
spent a lot of time a few years back in FamiTracker [2] to write music for it.
I always found it interesting that the Famicom had the ability for cartridges
to include their own audio hardware in addition to the mapper, battery-RAM,
etc. Like the mappers, the vast majority of these games that included
expansion audio chips kept to a small-ish set of chips. Chiptune (especially
Famicom chiptune, due to the time I spent tinkering with it) is a fascination
of mine, so I could point out some samples for the various expansion audio
chips if anyone would like.

[2] [http://famitracker.com/](http://famitracker.com/)

------
pcunite
This same person has made a simplistic clone of MineCraft in C.

[http://www.michaelfogleman.com/craft/](http://www.michaelfogleman.com/craft/)

------
billymeter
Great! It's an interesting experiment, eh?

A couple of other students and I did this same thing, but in Python, for the
final project in our Python class. The result was excruciatingly slow. It
still has some bugs, and we haven't touched it in almost a year, but we all
learned a lot along the way. If you're interested in taking a look, or
providing some feedback, the repo is here:
[https://github.com/billymeter/pynes](https://github.com/billymeter/pynes)

~~~
mind_heist
wow ! this one is cool ! From looking at the Repo - I see that you have used
pygame in your project. So , how did it help in implementing the Emulator ?

------
yodsanklai
Congratulations for this nice project. I wonder, how to write such an
emulator? My initial idea would be to write an interpreter for the processor
instruction set with a big array representing the RAM. Then some callback
functions are registered via openGL. They are called when there are some
inputs (eg. joystick). When this happens, they put something in the simulated
memory (some mapped area for I/O or specific registers) and set up some
interrupt flags. Does it make sense? then how to simulate accurately the
processor (and coprocessors ?) frequency? any other difficulties I haven't
seen?

~~~
mattdotc
I believe you're thinking along the right lines. If you're really curious to
learn more, check out this series which I have enjoyed reading:

[http://imrannazar.com/GameBoy-Emulation-in-
JavaScript](http://imrannazar.com/GameBoy-Emulation-in-JavaScript)

------
yamaneko
I would like to learn how to do that. For curiosity, why did you use Go? Is it
a matter of speed or libraries? Would you get the same result if you used
Python?

------
emodendroket
Cool. I've always wanted to make an emulator and this article makes it seem
less intimidating than it would.

------
bigjoecumbo
Check out the source code...it's surprisingly good!

