Smolnes: A NES emulator in less than 5000 significant bytes of C++ | Hacker News Reader

Smolnes: A NES emulator in less than 5000 significant bytes of C++

github.com

142 pointsjpegqs25 comments

Those who enjoy this might also enjoy "Creating a NES emulator in C++11" [0] [1] [2] while not short in bytes of code(space) there is a nice video series short in minutes(time).

Bisqwit takes you on a 30 minute tool assisted coding journey of making an NES emulator and also provides a 15 minute followup Q&A video explaining different aspects.

[0] https://www.youtube.com/watch?v=y71lli8MS8s

[1] http://youtu.be/XZWw745wPXY

[2] http://youtu.be/QIUVSD3yqqE

Bisqwit's nesemu1 source is 940 lines at https://bisqwit.iki.fi/jutut/kuvat/programming_examples/nese... It also uses SDL.

NES emulation is a great low level programming project and the tradition will probably continue for some time.

To save you a click, the video is someone speed-typing the source code to an emulator, with no commentary or explanation. You'd probably be better off reading the final result yourself.

> with no commentary or explanation.

Enable subtitles/closed captioning to see additional commentary provided by him about what is happening.

>the video is someone speed-typing the source code

They are not actually typing it at all, from the faq https://bisqwit.iki.fi/jutut/kuvat/programming_examples/nese...

  Q) Is the video sped up? Or, is that your real typing speed?
  A) No, it's not sped up. But the input is pre-choreographed. The computer
     implements the choreography, as well as designs a part of it.
     It is a TAS, except I'm not speedrunning; I'm just aiming for
     15 minutes and to utilize it in the most entertaining manner.
     My typing speed is not the focus of that video; it is not even
     being presented except in a small part of the 2/2 video.
     The focus is in the source code.

He actually wrote his own editor that he uses in the video and I believe that assists with the choreography.

Yes, my point wasn't at all about the speed. You can replace "speed-typing" with "displaying at a speed too high to read, much less think about".

If you want to understand how a NES emulator works, I highly recommend javidx9’s videos: https://youtube.com/playlist?list=PLrOv9FMX8xJHqMvSGB_9G9nZZ... I personally got more joy watching that series than out of HBO shows.

While reading the code I stumbled upon "case 1 ... 10:” or similar and asked myself how I could have missed this range feature for so many years. It turns out that this is a GCC extension and indeed not part of the language. A list of the C extensions (and C++ extensions) can be found here: https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/C-Extensions.ht...

That's true, I should have mentioned that I use this extension. It is supported by clang as well, however.

Big fan of this author's work.

They have a Gameboy emulator written in C, which can be compiled to WASM and run in the browser.

https://github.com/binji/binjgb

I learned a lot from the code.

Also I love this project with a bunch of demos in hand-written WebAssembly Text (WAT) format, which is like low-level Lisp that works only with raw memory, numbers, and minimal syntax.

https://github.com/binji/raw-wasm

Then I discovered the same author is quite active in the WebAssembly ecosystem, including specs and tooling. Fascinating stuff!

https://github.com/WebAssembly/spec

https://github.com/WebAssembly/wabt

Thanks! I don't work much on WebAssembly anymore, but I'm super excited to see all the progress being made.

Sometimes I think I'm good at programming, then I find something like this and I'm put back in my place.

A great resource for learning how to write an NES emulator is the Jakt NES monster video series [1] which covers writing the entire emulator where JT shows how to map specs of each instruction to code. The source code uses Jakt's modern syntax making it very readable [2].

[1] https://www.youtube.com/playlist?list=PLP2yfE2-FXdQBRpnZbcOb...

[2] https://github.com/jntrnr/jaktnesmonster

Hi all, author here! Happy to answer any questions y'all have

IOCCC entry? Tiny emulators seem to appear there semi-regularly, e.g. this one was memorable years ago: https://news.ycombinator.com/item?id=18198374

This was brought up for the last one of these I made, but the code here is c++ so wouldn't be allowed. I don't use a lot of c++ features, but it might be hard to keep the code size small without them.

This is the same person who made pokegb, a similarly tiny Game Boy emulator: https://github.com/binji/pokegb

I did something similar, but couldn’t figure out a clever enough way of resampling the audio from “native” rate down to something that Windows was happy with. What was your strategy?

I didn't handle audio for this emulator. But you can see how I handle resampling in my more fully-featured NES emulator here: https://github.com/binji/binjnes/blob/ca6977469168069a165176...

I'm not sure it's the right technique, but it seems to work pretty well!

Well, 5000 bytes of C++ plus the SDL library.

The emulator receives keyboard input from SDL and generates a framebuffer which it passes back to SDL. SDL is only used to handle the grunt work of reading keyboard input and displaying the framebuffer in a window, which is not the interesting part of writing a NES emulator.

It's also not a necessary part of an emulator -- it's actually easier to write an emulator that reads controller inputs from a TAS movie file and writes its output to a video file. Making it interactive is just more fun.

SDL isn’t the emulator. It’s the hardware.

Even IOCCC allows SDL (for example, 2005/jetro [1] is the only entry that used SDL_Audio as far as I know), so it is not that significant.

[1] https://github.com/ioccc-src/winner/blob/master/2005/jetro/j...

I guess I agree with the other comments here. The SDL is an abstraction that allows this emulator to be a bit portable. You could target this to some microcontroller with a framebuffer in hardware and then SDL disappears, you write directly to the framebuffer and read the inputs directly from some GPIO.

you got me, though using SDL doesn't seem quite as fair if you use that title :P

nice work though. I have been writing a compile-eval NES emulator in multiple languages, C++, Rust and such, it was a lot of fun. Still haven't managed to get it working with Rust, I still have hope.

> you got me, though using SDL doesn't seem quite as fair if you use that title :P

The program would still be sitting on top of an OS, unless it was a booter, at which point it would be sitting on top of device firmware, which sits on top of specialized hardware. SDL is about as generic a library as it gets when it comes to game development. Compare all of the companies that get credit for making their own first-person shooters, when all they had to rely on was a first-person shooter engine and a bunch of licensed assets. Scrabbling in the very dirt and clay, they are.

Reply on news.ycombinator.com