Poll of the Day > Writing an NES emulator ama

(+) Yeah! (+)

There are already 40+ NES emulators out there but I want to make one just so I can learn emulation better. Here are some key things that you might not know;

The CPU is the NES. When you provide it power it just starts moving memory around which makes other things happen. You could violently rip out the other parts, and the CPU would keep chugging, probably kind of confused.

The CPU has a number inside it that tells it where to get its next instruction. That number has a max value of 65535, so that's how many "things" it can see. Some of those values lead to nothing, some lead to what's in the RAM, what's in the ROM, and two of those addresses tell it what buttons are being pressed on the controller.

Here's a log of my CPU executing 10 instructions on a ROM called "nestest.nes". I'm able to tell if it's doing things right by comparing it to a similar log that's basically the cheat sheet to the test. You might notice that these are assembly instructions. It runs until it hits an instruction that I haven't added, I have 22/151 instructions. It gets through 72 before hitting one I haven't done yet.

1 C000 4C F5 C5 JMP $C5F5 A:00 X:00 Y:00 P:24 S:FD CYC:7
2 C5F5 A2 00 LDX #$00 A:00 X:00 Y:00 P:24 S:FD CYC:10
3 C5F7 86 00 STX $00 = 00 A:00 X:00 Y:00 P:26 S:FD CYC:12
4 C5F9 86 10 STX $10 = 00 A:00 X:00 Y:00 P:26 S:FD CYC:15
5 C5FB 86 11 STX $11 = 00 A:00 X:00 Y:00 P:26 S:FD CYC:18
6 C5FD 20 2D C7 JSR $C72D A:00 X:00 Y:00 P:26 S:FD CYC:21
7 C72D EA NOP A:00 X:00 Y:00 P:26 S:FB CYC:28
8 C72E 38 SEC A:00 X:00 Y:00 P:26 S:FB CYC:30
9 C72F B0 04 BCS $C733 (?) A:00 X:00 Y:00 P:27 S:FB CYC:32
10 C735 EA NOP A:00 X:00 Y:00 P:27 S:FB CYC:35

What's it doing?

It starts at C000 (hex)
1 JMP: It's jumping to that memory location. Aka, it sets the number it looks for its next instruction to C5F5. Notice how the memory address changes after this.
2 LDX: Load that value into the X register. A register is a byte that the CPU keeps internally so it can access it faster. It has several of these.
3 STX: Store the X register value in that memory location. It's setting those memory addresses to 0.
4 JSR: It's jumping to a location and storing the return address on the stack. Later, when it hits a "RTS" instruction, it will pull this value from the stack and come back to this point in memory.
5: NOP: Just do nothing for a little bit.
6: SEC: The has a status register. It uses all 8 bits of this byte as individual true or false values. In this case, it sets the "carry" flag to 1. This one 0000_000c.
7: BCS: And immediately after that, it checks to see if the carry flag is set. If the carry flag is set, it will jump to another location. And it is, so it will.

Nifty.

6502 architecture is lots of fun and I find it to be a lot better than 8008 and whatever the z80 one is called.

edit: I also recommend checking out 3Dsen on Steam

Yeah people always say to start with chip8, but idc about chip8, I've never heard about it in my life.

The only weird thing is dealing with the many different kinds of mappers that ROMs used, which basically put the ROM somewhere in the 64kb address space, as well as any RAM that came with the cartridge itself. After that, you spend a week or so doing every opcode, and apparently the PPU is simple enough to get done quickly, then you can play Mario.

But the reason movement is kind of janky on the NES is that the NES did not support any kind of decimal number. There is no 0.5 on the NES. And the dumb thing is that the 6502 did support decimal arithmetic, it's just they disabled it because they were using a bootleg chip that was based off the 6502, and it's speculated that they disabled the decimal functions to avoid a lawsuit.

It's in a nice middle ground where it's complicated enough to make a good emulator that you might even use, without taking years to complete. ("complete" an emulator, yeah that never happens)

71/151 opcodes implemented for the CPU

The CPU is halfway done. This is a grind.

https://gamefaqs.gamespot.com/a/forum/a/a4f6a99d.jpg

https://gamefaqs.gamespot.com/a/forum/7/7cf204f7.jpg

Curious: Where did you learn how to do systems programming?

I think I have an idea for what I want to do with this. I use MonoGame as the graphics library, which is easy to use casually, I should make it so you can create plugins for NES games and just hook into the game logic. Like creating a giant 3D goomba in SMB1 that you can interract with that just inserts itself into the emulation. It would be a new approach to modding (not brand new, some SNES emulators do this with LUA?)

Maybe I'll switch to Godot. I like Godot and I like the idea of promoting it.

I should also support Mesen HD graphics packs.
https://www.youtube.com/watch?v=qYDzL5hVzSM

EclairReturns posted...

Curious: Where did you learn how to do systems programming?

I read the NESDev wiki
https://www.nesdev.org/wiki/Programming_guide

If I didn't understand something I just Googled it and spent an hour reading random things about it until I understood it better.

I also have the output log of a known working emulator so I know if mine isn't working through any guesswork/mistakes.

sounds fun. looks like C#, right?

Yellow posted...

After that, you spend a week or so doing every opcode, and apparently the PPU is simple enough to get done quickly, then you can play Mario.

that almost sounds not too bad except what about graphics and audio? isn't there some kind of sprite system, etc? how does that work? and how do you play 8-bit audio? maybe there are libraries for this? (I see PPU is the graphics but that doesn't sound easy).

Are you going to charge for it and get sued by Nintendo?

Sahuagin posted...

sounds fun. looks like C#, right?

Yeah, that's just a big array declaration with one of the parameters being an array of delegates. I use this coding pattern a lot. C++ is used very often in emulators because people think it's faster, but that's a myth. It uses more memory and will chug if you don't know what you're doing, but with the latest .NET JIT optimizations generally any code you write will be just as fast as a compiled language. C/C++ diehards think I'm over here creating a new object to spam the GC every frame, when even amateur C# users know not to do that. Proof of that is RyuJinx, a switch emulator that (ran) as fast as the C++ Yuzu despite being written in C#.

Sahuagin posted...

that almost sounds not too bad except what about graphics and audio? isn't there some kind of sprite system, etc? how does that work? and how do you play 8-bit audio? maybe there are libraries for this? (I see PPU is the graphics but that doesn't sound easy).

I've only been told the PPU is easy, I haven't actually gotten to it yet. So I'll do my best to explain what I know so far about those things;

The sound is controlled via the APU, which takes parameters and outputs a couple waves accordingly. "two pulse wave generators, a triangle wave, noise, and a delta modulation channel for playing DPCM samples"
https://www.nesdev.org/wiki/APU

How it works is essentially this; the CPU writes values to the a certain area. The APU has some registers mapped to that area, the APU reads these values (just like parameters) and outputs sounds accordingly.

The PPU acts the same way, taking only 8 registers as parameters. I can't say much more about it confidently because I haven't gotten to that part yet, but the CPU can work without it.
https://www.nesdev.org/wiki/PPU

Ogurisama posted...

Are you going to charge for it and get sued by Nintendo?

Nothing I do is popular enough for that, but I hope they have the courtesy to DMCA me first at least. I don't think I will do a Patreon even if it does get popular.

If Nintendo starts throwing tomahawks at random NES projects (others are first) I'll start worrying about that.

Yellow posted...

C++ is used very often in emulators because people think it's faster, but that's a myth.

I know what you mean yes. I usually follow the rule of thumb "premature optimization is the root of all evil". once something works, then profile it and optimize it (if necessary).

Yellow posted...

How it works is essentially this; the CPU writes values to the a certain area. The APU has some registers mapped to that area, the APU reads these values (just like parameters) and outputs sounds accordingly.

I mean though that you would have to also implement the APU instructions, which would require playing 8-bit audio on a modern system, somehow. (or something, not sure). same with graphics, you will need to have a graphics library and render to a surface and present it to the screen, etc.

I just made the repo public since it's getting some actual progress done
https://github.com/jamieyello/MNES

Sahuagin posted...

I know what you mean yes. I usually follow the rule of thumb "premature optimization is the root of all evil". once something works, then profile it and optimize it (if necessary).

Idk if it's because C# is a higher level language but I generally write keeper code off the bat so I don't have to do it again. For the NES, I really don't have to worry about optimizations outside of obvious mistakes like looking through a big list every frame, since it's not demanding anyway.

Here's an example of not optimizing that's just bad practice, 3 years ago I attempted an NES emulator. It's much sloppier and worse written. Instead of indexing all opcodes and their methods in an array to be called directly, I just created a giant switch statement with all opcodes. This is surprisingly very common practice for NES emulators.

Old;
https://github.com/jamieyello/JNES/blob/master/NES/Machine.cs#L415

New;
https://github.com/jamieyello/MNES/blob/master/MNES.Core/Machine/CPU/Cpu.cs#L151
(which then gets indexed here)
https://github.com/jamieyello/MNES/blob/master/MNES.Core/Machine/CPU/Cpu.cs#L792

Sahuagin posted...

I mean though that you would have to also implement the APU instructions, which would require playing 8-bit audio on a modern system, somehow. (or something, not sure). same with graphics, you will need to have a graphics library and render to a surface and present it to the screen, etc.

I'm pretty familiar with MonoGame/Godot, and graphically I think both of those will be adequate enough to use without even writing shader code. At worst I'll have to do a palette swap shader.

As for audio, I assume that base .NET will have something to manage waveforms and output those as soundwaves, or a nuget package will exist to do it for me. Or I'll just write it custom.

yeah well

https://www.youtube.com/watch?v=ON-vArvervA

that guy made an nes cart play nes games

it can even play itself

Yellow posted...

I just made the repo public since it's getting some actual progress done

hmm. a hobby C# NES emulator...

FYI I will be strongly tempted to contribute, or at least make suggestions, though I have very little time and energy, and I'm not terribly familiar with the etiquette of coding with others.

(I think I slightly overdid it the last time, but I'm not sure what to avoid or not avoid. maybe I should just work on a fork that I keep updated and not worry about merging my changes into yours.) (last time I was relatively new to git but have been using it quite a while now.) (due to the limited time and energy I may not be able to do much even if I want to.)

Seem to be missing types in the namespace MNES.Core.Machine.Log
Nullable disabled in MNES.Core?
Are you ok with file-scoped namespaces?
do you have any particular coding conventions that I should adhere to such as braces, etc? (I will try to use 4 spaces though I am used to 3)
let me know if I'm too annoying (as soon as there's a second dev things get a lot more complicated so if it's too much definitely let me know and I'll just work separately)

Sorry I had to go to sleep lol. I am nocturnal ATM, will be able to reply more later.

Yellow posted...

Nothing I do is popular enough for that, but I hope they have the courtesy to DMCA me first at least. I don't think I will do a Patreon even if it does get popular.

If Nintendo starts throwing tomahawks at random NES projects (others are first) I'll start worrying about that.

You're probably safe unless you're stupid about it like Yuzu was by selling cracked copies of games. If Dolphin can keep going strong for 20+ years with barely a whiff of legal trouble you're probably fine to continue.

el_cheato posted...

You're probably safe unless you're stupid about it like Yuzu was by selling cracked copies of games. If Dolphin can keep going strong for 20+ years with barely a whiff of legal trouble you're probably fine to continue.

Yuzu didn't sell cracked copies, I think at worst some mod or developer linked to a pirated copy in their discord. They also took a settlement, which doesn't really set any precedent or even confirm they would have lost. Another thing is that they had an LLC set up, so most likely no developer is going to pay a dime.

The lesson to be learned from Yuzu is that you don't take $30k a month emulating superior ports of Nintendo's games on day 1 and then immediately fold in court because obviously they're going to put pressure on you. But most likely they were a bit screwed because of one or two off handed comments made by developers in the discord involving piracy, and they worked out a mutually beneficial deal where the developers wouldn't suffer real consequences while scaring the emulation community as much as possible. The whole "keys" thing doesn't even hold water, they didn't do anything wrong there, it was just a settlement.

Sahuagin posted...

hmm. a hobby C# NES emulator...

FYI I will be strongly tempted to contribute, or at least make suggestions, though I have very little time and energy, and I'm not terribly familiar with the etiquette of coding with others.

(I think I slightly overdid it the last time, but I'm not sure what to avoid or not avoid. maybe I should just work on a fork that I keep updated and not worry about merging my changes into yours.) (last time I was relatively new to git but have been using it quite a while now.) (due to the limited time and energy I may not be able to do much even if I want to.)

Having had some experience developing with others on community projects, I am opposed to fork/branch spam lol. It's the real rookie mistake.

The optimal workflow for a small casual team is on the same branch kept in sync as often as possible with minimal oversight from one single person. Forks are for entirely new repositories that are not meant to merge again. Branches are either for large reworks/revisions, or keeping a version of the source available from different points in time, like a "release" and "development" branch. That said a forum where short frequent casual messages can be sent is very useful for communication, like discord. I'm just going to set up a forum real quickly here where we don't have to spam PotD

I've had to deal with a lot of devs creating 6 branches for each person, and then they get upset when their work got lost here and there and came to me to fix it (even though they could go into the git history and fix it the same way I ended up doing). I ended up managing everyone else's work, which took time out of implementing the core of the code myself.

I find it much easier to review and merge smaller commits instead of one massive branch. I didn't discard any of the changes you made last time at any point, btw. I'm not a snob about commits or formatting or anything. I've accepted lots of commits by "junior" devs and usually spend a lot of time helping them improve, because community projects are all about having a good time anyway. Not to imply that you're a junior dev.

If you want a rundown on how the code works, it's actually very simple at the moment and I'm trying to keep it more "legible" than "genius level", if that makes any sense. Don't worry about screwing anything up, the history is right there and I can just as easily fix it anyway. Any time you feel like working on it I can easily point you in the right direction, an emulator is easier to coordinate since it's a very objective goal.

Sahuagin posted...

Seem to be missing types in the namespace MNES.Core.Machine.Log
Nullable disabled in MNES.Core?
Are you ok with file-scoped namespaces?
do you have any particular coding conventions that I should adhere to such as braces, etc? (I will try to use 4 spaces though I am used to 3)
let me know if I'm too annoying (as soon as there's a second dev things get a lot more complicated so if it's too much definitely let me know and I'll just work separately)

Yeah any namespace issues you describe are accidental on my end.

I've mostly stuck to the formatting that you used last time since I really liked your style of fitting as much stuff on the screen as possible. I've stuck to that idea ever since. Idk how I feel about using 3 space indents, but sure, let's do that. I liked everything else you did last time.

If () {
}

I sent you an invite to this org as an owner.
https://github.com/MNES-Emulator

This is the "forum" (this is preferable to Discord imo since everything is search indexed)
https://github.com/orgs/MNES-Emulator/discussions

Anyone can post here but you and I are maintainers of the org.

I'm about to make a YouTube video essay on why you should never never never use float. In response to this.

https://www.youtube.com/watch?v=E7kCFkFi0Cc

What takes up more space, float or double? What about a float[100] and a double[100]? What about a bool[100]? Ask any programmer and 95% of them will tell you the wrong answer. All of them take up the exact same amount of space, array or not. A bool, something that's either true or false, takes up 64 bits in memory.

A bool[3] in memory looks like this;
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000001 true
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000001 true
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000001 true

An int[3] in memory looks like this;
00000000_00000000_00000000_00000000_11111111_11111111_11111111_11111111 0xffffffff
00000000_00000000_00000000_00000000_11111111_11111111_11111111_11111111 0xffffffff
00000000_00000000_00000000_00000000_11111111_11111111_11111111_11111111 0xffffffff

And these tests prove that they're not more demanding;
https://pastebin.com/3MVXpUik

So why would you ever use float? You wouldn't. You would only assume you are suffering from Dunning Kruger because literally everyone gets this wrong. float is a relic of 32-bit machines. double, originally took up 2 address spaces. Today it only takes up one. And your CPU does work on all bits synchronously, so it literally does not matter how many of those 64 bits you use in regards to speed or memory usage.

Likewise! long is objectively superior to int, another type that (if not for legacy costs) should not be used anymore!

Why is it that every top voted answer on StackOverflow suggests saving memory/performance by using int/float??? All these valuetypes are lies, each and every one of them is a long on your 64-bit machines.

Why is it that modern game engines still use float for X/Y/Z? They should absolutely not. The only engine I know of that gets this right is Unreal Engine.

To "fix" starfield you have to modify the assembly of the engine and force it to use double instead of float. Then you can have planet sized worlds. You will have to patch it a lot but it's not impossible.

Yellow posted...

I've mostly stuck to the formatting that you used last time since I really liked your style of fitting as much stuff on the screen as possible.

that's kind of it yeah; it's that you should justify usage of vertical space. sometimes using more vertical space is ok to keep things readable, but sometimes things can be compressed and still be quite readable and maintainable. and some people do things that waste vertical space not realizing how much that hurts readability. but there is a middle-ground somewhere.

we don't have to switch to 3 spaces just for me. the challenge of "how do I use different tab sizes in different projects" is one I haven't dealt with before and something I should learn. (my switch to 4 yesterday made it work today since I have the same JetBrains account in both places and I guess it saves the setting to the cloud or something. (doesn't matter, it's easy to change the setting))

the challenge for me right away is that seeing your code there are 100 different style decisions that I would make differently and I have to decide whether I should change the code or myself to proceed. (FYI I am not always right; in fact I try to actively be in search of places where I'm wrong.)

I will try to make simple commits and merge often.

my approach lately is to do each "task" on a separate branch. branches are rebased onto master if master grows, and when a task branch is finished it is merged into master with no fast-forward and then deleted. this results in a very clean commit history, though the commits will not be in 100% chronological order (each branch is, but each branch is listed whole even if it was really concurrent with other ones). I'm not 100% sure how this translates to github.

I'm now remembering how much effort it takes to communicate these kinds of things through text.

Yellow posted...

Forks are for entirely new repositories that are not meant to merge again.

hmm, I sort of know what you mean, a real "fork" is meant to permanently diverge.

but from my past understanding the last time I used github to contribute it is necessary to work on a fork, I think. I fork your repo (on github) and then I clone my fork. I keep my fork updated against yours, and I keep my local PC updated against my fork. I then push to my fork (since I have write access to it and not yours) and then I make a pull request to your repo from my fork. (I don't think you can make a pull request from CLI git? or maybe you can? in that case I don't know why I'd use a fork then.)

the "fork" in this case is just a temporary place to give me write access to github and a place on github from which to send a pull request.

let me know if I have a part of this wrong.

I will try to do something simple today and you can reject it if it's not working for you.

I don't think what you've said about floats and bools is correct. floats are 4 bytes/32 bits. doubles are 8 bytes/64 bits.

bools are in many places 4 bytes/32 bits, except in arrays they are 1 byte (each).

I don't have a hexdump of memory to confirm this, but some quick tests do seem to confirm it: https://ideone.com/4ELLjh

Size of a single Single in bytes is 4.
Size of a single Double in bytes is 8.
Size of a single Boolean in bytes is 4.
An array of type Single of size 5 takes up 20 bytes.
An array of type Double of size 5 takes up 40 bytes.
An array of type Boolean of size 5 takes up 5 bytes.

Sahuagin posted...

I don't think what you've said about floats and bools is correct. floats are 4 bytes/32 bits. doubles are 8 bytes/64 bits.

bools are in many places 4 bytes/32 bits, except in arrays they are 1 byte (each).

I don't have a hexdump of memory to confirm this, but some quick tests do seem to confirm it: https://ideone.com/4ELLjh

Hmm, ok, that probably checks out, but I'll have to look into it later. I hope you're at least a little bit impressed by my habit of assuming everyone else is wrong about something basic except me (I swear it's not an ego thing). "I'm not wrong the compiler is" syndrome.

Sahuagin posted...

hmm, I sort of know what you mean, a real "fork" is meant to permanently diverge.

but from my past understanding the last time I used github to contribute it is necessary to work on a fork, I think. I fork your repo (on github) and then I clone my fork. I keep my fork updated against yours, and I keep my local PC updated against my fork. I then push to my fork (since I have write access to it and not yours) and then I make a pull request to your repo from my fork. (I don't think you can make a pull request from CLI git? or maybe you can? in that case I don't know why I'd use a fork then. (didn't get it to work))

the "fork" in this case is just a temporary place to give me write access to github and a place on github from which to send a pull request.

let me know if I have a part of this wrong.

I will try to do something simple today and you can reject it if it's not working for you.

Yeah forks are necessary if you don't have permission, if you accept the organization invite you should be able to push directly to the repo. Then you can ask for forgiveness and not permission.

That's the CPU fully implemented. It should in theory currently be able to play SMB1/Ice Climbers/other mapper 0 games without graphics/sound.

I had an idea for features, I'll create an interface In Godot that will let you swap out your playable character with another. Say you want to play as princess peach in SMB3, the emulator will hook into behaviors and override sprites/movement code, and allow the code/graphics to be implemented with C# instead of the limited NES assembly. That's some potential for going viral right there, lots of YouTuber challenge videos, so I'll have to be careful about copyright else I get nuked. Should I consider getting DMCA'd by Nintendo a badge of honor?

So how does an antiquated CPU like the NES realize when it needs to handle drawing another frame? Does it carefully count to 30,000 and insert the PPU (Picture Processing Unit) interaction code? Does it check the state of the PPU every now and then?

No, it defines a method at a certain location to handle communication with the PPU (the PPU can't communicate while it's drawing, it's too busy of course). When the PPU is ready, it will set a flag to true. Before the CPU executes any instruction, it checks for that flag, and if the flag is set, it will jump to PPU code, and then return when it's done, and that's what a CPU interrupt is.

It now boots into a game and runs a couple frames before crashing with a partially implemented PPU (picture processing unit). Still no graphics, but I'm surprised to see it working this much.

Now I have to build out a UI using Godot and draw the PPU buffer to the screen, and from there it should start rendering graphics.

https://gamefaqs.gamespot.com/a/forum/6/65ce6152.png
https://gamefaqs.gamespot.com/a/forum/d/df697beb.png
https://gamefaqs.gamespot.com/a/forum/1/1617d424.png
Everything is fine

It actually runs the test rom with corrupted graphics. And it's so optimized already, it only uses 1.5 GB of memory! Despite that, it only uses ~1% of CPU power.

Yellow posted...

And it's so optimized already, it only uses 1.5 GB of memory!

just like GooglePlay, so you know that's quality

Is it ready to play the shitty NES games I own on Steam?
https://gamefaqs.gamespot.com/a/forum/a/ab4eff9a.jpg

DeltaBladeX posted...

Is it ready to play the shitty NES games I own on Steam?

The only real compatibility issue is that NES cartridges all used different mappers, some of them literally added hardware to the NES. That game used MMC3, which is one of the easier ones to do.

You know how Kirby and SMB3 were able to scroll diagonal and that was amazing how the genius devs were able to learn and optimize the hardware like that? That's what I though, but no, they literally just added the ability to do that with the cartridge. Some Youtube video gave me that misinformation 9 years ago.

Lokarin posted...

just like GooglePlay, so you know that's quality

Yes, time to slap 50 ads and trackers on it and send it to the play store. You consent to being tracked, right?

Yellow posted...

You consent to being tracked, right?

silly fool; you are by default tracked... you have to specifically opt out now!