Yes, it's real, and it works. (well, mostly)

It took a while to make, so check it out:
https://scratch.mit.edu/projects/561973653

Hope you enjoy playing Balloon Fight at a comically low framerate!

woah cool

Alright, since this emulator is finally getting some attention,
here's the obligatory Q&A forum post.

Q: Why is it called “Cool NES emulator?”
A: Because I suck at naming things

Q: When will it have a GUI?
A: When I have enough time to actually add one.
If you don't want to wait, @oxiti8 has already made a GUI for the emulator!
There's even instructions for converting ROMs on Windows:
https://scratch.mit.edu/projects/578387561

Q: I tried to load a game, but it says “Unsupported mapper X!”
A: That means the game's mapper chip isn't supported yet.
If you don't know what “mapper chip” means, then google “Nintendo MMC”.

Q: Why do games have no sound at all?
A: Because the APU (sound chip) hasn't been implemented!
Even if I added it, it would just hurt your ears because the game runs too slowly…
Doesn't mean I won't add sound, I just want to spare your ears

Q: I looked at the code and found an APU sprite!
A: That's just for the APU's frame interrupt. Doesn't play any audio ¯\_(ツ)_/¯

Q: Why do some games run slower than others?
A: It depends on all sorts of stuff, all you can do is hope that the game runs fast
In general, games that use mappers will be pretty slow, so stay away from those if you want good performance. Games that use mappers are always larger than 40KB.

Q: Will the emulator ever run faster?
A: Of course, there's all sorts of stuff that can be optimized!
It's pretty difficult though, because there's no way to tell if a change in the code will increase or decrease performance…
As always, the easiest upgrade is a faster computer

Oh boy, here comes the technical stuff:

Q: How accurate is the emulator?
A: In terms of “how many games work?”
I have no idea! I simply don't have the time to test every game and complete them.
Some games have bugs right off the bat, others may have some weird glitches near the end of the game.
Out of the 30+ games I tried, I've found a few glitches. It's not anything that can't be fixed though!

In terms of “how accurate is the CPU/PPU?”
That's a long story… in short:

CPU is pretty good. It passes blargg's CPU instruction test and CPU timing test. It also supports unofficial opcodes. (well, except for the really unstable ones)
(as i typed this, i realized the timing test is broken on the latest version… youll just have to take my word for it)
PPU is decent. It uses a per-scanline system, so it's not cycle accurate. But it gets the job done, so who cares
APU is just a shell. Doesn't play any audio.
Mappers are like a hack job at best… bankswitching is done by replacing a “rom” list (visible to the CPU) with values from a larger “prg_rom” list (the actual ROM data). Same thing for the PPU.
It's pretty slow but as always, if it works, who cares?


Wow, now THAT'S a long forum post… hope it doesn't get removed…

GenericHeroGuy wrote:

Q: I looked at the code and found an APU sprite!
A: That's just for the APU's frame interrupt. Doesn't play any audio ¯\_(ツ)_/¯

Actually, Kouzeru is working on a remix with the APU implemented! It''s slow right now but sounds pretty decent.
Also there are ways to speed up your CPU- something to do with having more common opcodes more easily accessible than the ones used the least- I'm not the best person to explain it though.

oxiti8 wrote:

GenericHeroGuy wrote:

Q: I looked at the code and found an APU sprite!
A: That's just for the APU's frame interrupt. Doesn't play any audio ¯\_(ツ)_/¯

Actually, Kouzeru is working on a remix with the APU implemented! It''s slow right now but sounds pretty decent.
Also there are ways to speed up your CPU- something to do with having more common opcodes more easily accessible than the ones used the least- I'm not the best person to explain it though.

Yup, that's me, thank you for the mention! I'm deep on knowledge of implementing the APU for Scratch,
I had worked for MicoTracker since more than 6 months ago. It's basically NES music tracker, which is currently being playbacker. (press m to switch from audio buffer mode into synthesis mode; and it's the synthesis mode will be implemented as your apu; key 0123456789 to turn on/off individual channel)

The optional change I could make to your emulator is optimizing how you transverse opcodes. There'd I'll try to do huffman tree, based on frequency each opcode's execution
(apparently 4C opcode executed the most)

Another optional things would be optimizing the PPU, and the optimization of it will be inspired by DCPU-16's gbc.sb2 gameboy emulator, which is basically an RLE-style drawing.

Topic moved to Advanced Topics, at the advice of oxidi8
https://scratch.mit.edu/discuss/topic/547741/