My unpopular opinion is to emulate an extremely reduced subset of x86. For example, jump to main and emulate the result of `int main() {return 2;}` compiled with gcc. You already have the compiler (no need to cross compile), you already have the decompiler and you can run the binary on the reference machine without an emulator. You save so much time having this entire toolchain already and you can start emulating simple C programs for x86 with <10 instructions and 1 or 2 addressing modes. I've written about this process before in Node and Go [0].

Yeah everyone will comment after me that x86 gets way more complex over time but if you just want to get a quick intro and you aren't a perfectionist x86 is kind of compelling.

And recently I wanted to try emulating MSP341 at someone's recommendation because it has a very simple architecture. But just getting a C compiler for it isn't easy! When I've tried to cross-compile C to other archs like RISC-V it also wasn't straightforward and I just got stuck in this toolchain spot.

If it were easier to cross-compile simple languages like C then writing emulators for other environments would be easier.

If you're on a new Mac, my whole argument applies for aarch64 instead of x86.

[0] https://notes.eatonphil.com/tags/emulators.html

But emulating the CPU is probably the least interesting part about writing an emulator for a video game system. Writing the other hardware components and getting them to work together is the interesting part imo. I'd say skip writing your own CPU emulator and just start with someone else's.

As a backend dev, being able to emulate my own program compiled with GCC was pretty rewarding personally.

But I'm not arguing everyone must do it. Just trying to share why one unintuitive approach (the "complex" x86 architecture) might actually be easier and cooler than you think.

I thoroughly enjoyed what little I read of this, bookmarked it for later -- thanks!

https://notes.eatonphil.com/emulating-amd64-starting-with-el...

I wish there was an easy way to compile to a subset of x86 (e.g. mem access only with simple mov, only using one flag, no extensions, no floats, pure 32bit instructions).

Yeah that would be even more convenient!

> My unpopular opinion is to emulate an extremely reduced subset of x86

I don't think 808x is such an unpopular machine for approaching emulation.

Some people use Space invaders (or contemporary titles), which is based on an 8080, as stepping stone between CHIP-8 and more modern (complex) platforms.

Try your hand at a CHIP-8 emulator. The instruction set is really small, well documented, and easy to implement for your first project.

https://multigesture.net/articles/how-to-write-an-emulator-c...

I wrote (or tried writing) a gameboy emulator once.

My only qarning is that there are a lot of edge cases in the specification--and the proper specs are wrong.

I ended up spending most of the time searching through undocumented/missing CPU specifications. It became rather tedious.

For a learning project, this made it poorly suited. There are so many good emulators out there, the only reason to write one is for the learning experience. I just felt that I stopped oearning after a while and was just debugging obscure combinations of cpu states.

That was more or less my experience. I got the original Game Boy working well, and quite a few Game Boy Color games, but it eventually devolved into debugging CPU timing issues and edge cases with sprite bugs. At some point I realized that I had gained all of the knowledge I had wished to learn and since my own emulator was never really going to do anything that hundreds of others weren't already doing better I moved on. I will say it was a good learning experience however. Chip-8 is a good start, but there are lots of concepts that emulating a Game Boy will require that Chip-8 does not.

I'd recommend maybe trying something simpler, like a Motorola 6811 or a MIPS processor. Their instruction sets are pretty simple and straightforward. But, I can see how that might not be as fulfilling.

That seems to be the consensus that I've read online.

Still, the reason I want to do it online is specifically because I want an excuse to really understand low-level hardware. I (and probably a majority of people on HN who do software) really only have "real" experience with "Java or Higher" with maybe hitting C if I have the rare occasion of having to worry about saving a few milliseconds. An emulator would force me understand low level hardware, or at least I think it would.

Another fun option for learning low-level stuff is analyzing existing games. I did this to create a level map dumper for one of my favorite NES games[1]. You can see other ideas on the excellent Displaced Gamers YouTube channel, for example[2].

Also, read the book Code by Charles Petzold.

[1] https://tcrf.net/Proto:M.C._Kids#Level_Changes

[2] https://www.youtube.com/watch?v=zGdpst_6k9k

I think Nand 2 Tetris [1] is a really good way to get a good intro to this stuff at a basic level without too much friction with tools. You essentially start with a nand gate, and eventually build up a whole computer including a Java-like programming language.

[1]: https://www.nand2tetris.org/

I've been meaning to get to Nand2Tetris, it looks really interesting.

It is definitely a fun learning exercise, but also quite addictive and grueling (yes, a contradiction)!

I wrote a Gameboy Color emulator[1] earlier this year, but stopped as soon as I realized that I wasn't learning anything new. As a result, my emulator has a few issues and does not support sound, but it is able to run quite a few games. I also got it running in a browser via WASM, which was fun.

[1]: https://github.com/aksiksi/gbc

For a fun and fairly basic task, consider giving the 2019 advent of code a try. You will end up with a basic emulator for an imaginary machine, but you will get to solve interesting puzzles with it.

The UXN project might also be fun, the virtual machine is fairly simple to implement and there are a lot of interesting programs written for it.

  https://wiki.xxiivv.com/site/uxn.html

There is also the LC3 virtual virtual machine, with a fairly great guide on creating it.

  https://justinmeiners.github.io/lc3-vm/

There's a Chip-8 emulator running on Uxn

https://git.sr.ht/~rabbits/chip8uxn

The first emulator I wrote was for a virtual machine called the CHIP-8. I used CowGod's reference, it was a fun experience!

http://devernay.free.fr/hacks/chip8/C8TECH10.HTM#2.1

I forgot about CHIP-8. That might be a good starting point. Thanks for reminding me.

Try JimTCL, it uses SDL2 for "GUI"'s instead of TK, but it's as compatible (at code level, not TCL extensions, Jimsh uses its own ones) as TCL 8.5 so most stuff will work as is.

If you look at the examples, you'll find that writing a Chip8 emulator with JimTCL it's a breeze.

https://github.com/msteveb/jimtcl

I've written somewhere around 1/3rd of a NES emulator. It does the CPU, and the backround half of the PPU, but not foreground sprites, sound, controllers, or running at decent speed ;)

Anyhow, I found the CPU part a lot of fun, and there's public domain test roms with expected registers after each instruction that you can use to test and confirm. Interaction with other hardware and emulation of that hardware gets a lot more challenging. The gameboy is certainly different than the NES, but I suspect there's a lot of similarity at the high level. It's certainly reasonable to stop (or pause, perhaps), when it stops being so fun, too.

I'm also not sure porting an emulator is going to give you the same understanding as writing one, but maybe.

I wrote a decently complete NES emulator[1], and the 6502 is definitely a fun CPU to emulate compared to other CPUs. The Z80-ish CPU in the Game Boy is not as fun, and as soon as you get into 68000 territory, it definitely stops being fun for a hobbyist.

Getting the graphics and sound in sync with the CPU is a lot more challenging if you're looking to support many games, but if you just want to play some of the super simple early NES games, like Donkey Kong, then you can get away with a lot of inaccuracies.

[1]: https://github.com/ltriant/nes

My first "emulator" was a Brainfuck interpreter. Really simple to implement and understand

That's a great idea! I think you win for my weekend project...if nothing else it will be fun to bring up that I made a Brainfuck compiler.

If you think you can do it, you probably can. It's not really all that conceptually difficult until you want to do dynamic recompilation.

I wrote my first emulator a while ago, for the Gigatron. People recommend CHIP-8 a lot but I just thought it looked too trivial and uninteresting. The Gigatron is still incredibly simple, but it's also a really elegant little beast worth studying for its own sake.

Emulating old terminals is fun.

Start with a CHIP-8 emulator, it's a great first emulator to write that will expose you to a lot of core concepts without all the complexity that comes with more advanced systems.

A nice perk of writing an emulator is the exposure you’ll get when it hits the front page of HN and other tech news sites.