Everyone should do this once! I picked MSP430 because it was the simplest instruction set that GCC would compile for, and the process of building the emulator was every bit as pleasant as I'd hoped --- I got the compiler working, wrote a disassembler, and then iteratively built the emulator to get successively more interesting C programs to run on it. Took 2 weekends altogether. One of the best learning experiences of my career.
It's a good exercise, and one of those experiences that helps to take the magic out of things (which for many people is an intimidating barrier preventing further understanding and growth). Like writing a compiler, various network protocols, file parsers, operating system, or directly writing assembler (especially if you've always used higher level languages before).
For what it's worth, I found the emulator way easier than the codegen step for the compiler, and it's probably easier than the AST generation too. Can't say enough good things about banging out a crappy emulator sometime when you're bored. It's not a huge commitment!
Yea, it's a lot of fun. I did this with a 6502 over Christmas vacation years ago. Mind, it was a 6502 emulator, not a specific system. My goal was to get Fig Forth up and running on it. I wrote it in Java, and had my own console, as well as CPU level breakpoints and such for testing. It supported the simple "serial" console and simple block disk I/O.
So, not only did I write the emulator, I wrote an assembler to assemble the stock Fig source code.
It's hard to express how interesting it was testing unknown source code, with a buggy assembler, on a buggy CPU. For extra loads of laughs, my "benchmark" system that I happened to be testing opcodes and such against (for flags and what not) was a buggy web emulator. You just never knew what was going to go wrong where. Amazingly, I sussed it all out.
The good news is that the Fig source pretty much worked out of the box. Outside of my minor changes to adapt to my "I/O", it worked really well.
https://www.reddit.com/r/EmuDev/ is a great place to hang out if this topic interests you. They'll always suggest doing CHIP-8 as a starter project but my unpopular opinion is to just attempt to emulate basic x86 programs [0].
Having written a CHIP-8 interpreter, I'd agree with the popular consensus to start with it. x86 is definitely more ambitious though, and would be fun if someone had the right background knowledge needed already.
I wrote my first emulator recently, for no particular purpose. I didn't choose CHIP-8 because, frankly, it was just too trivial. Instead I went with the Gigatron. Still pretty straight-forward as far as these things go, but you have to handle a VGA signal and 4-bit audio DAC at least. It's also just a beautifully elegant machine worthy of study.
It's billed as a "debugger"... but it has an entire x86 emulator! The code is very small and clear. Written by national treasure Justine Tunney, of Redbean fame.
I'm considering modifying it to count x86 calls, to trace an executable running, to find hotspots and code that doesn't get called.
Author of Blinkenlights here. I wrote Blinkenlights because I wanted to be able to see my programs running and create MPEG videos on my blog that let people watch progs like SectorLISP run without having to run the code themselves. I also use Blinkenlights to make my software go faster. Commands like `perf record` are great for creating reports, but a lot of information gets lost in translation while aggregating like temporality, page faults, register spillage, and feature utilization. I also needed it to debug booting actually portable executables from bios in a way that could be embedded in a hermetic monorepo with automated testing and a TUI that's snappier and more pleasant to use than bochs or qemu. I wanted an x86-64 emulator that's about 150kb in size so it could be embedded in APE binaries so that they'll run on other cpu architectures. Finally, I wanted the ability to have a security layer where, for example, it's nice to have an emulator that's hackable enough where if some new rowhammer attack comes out then I can change the mapping of physical memory on the fly without having to recompile. It's hard to find software that creates a stronger barrier between software and the cpu/kernel. The only one I know that comes close is Bochs but it's GPL and gVisor but it's syscall-only and huge. It's also just a rare thing to want since all software, e.g. v8, tends to optimize hosted code down to metal on a long enough timeline, regardless of their original intentions, due to the constant push and pull between perf and sec.
I was responding to the PC's desire to write an analysis pass.
If perf isn't doing the job then you need to use a "proper" profiler like vTune. Perf is really good for the first pass but the analysis it provides is very superficial compared to a better profiler. This is better than analysis in an emulated environment as far as I'm concerned, most simulators don't even come close to mimicing a real processor (even gem5 isn't cycle accurate so if you are latency bound you may get the wrong result)
It also can track page faults, if you want to know where they happen you probably want perf mem
Would Blinkenlights be proper if I told you that it uses Intel Xed? I'm sure Intel vTune is wonderful but I probably can't use it since I usually don't have access to a desktop. I feel the same way about Valgrind. You have to generate the report, copy it over, spin up the VM, view it in KCacheGrind.
> Would Blinkenlights be proper if I told you that it uses Intel Xed?
Why would it? I have every faith that the tool is sound (i.e. parses X86 correctly etc.), I was just thinking aloud about this kind of analysis.
What do you need to optimize but can't run on a desktop? Or is this the same type of "optimization" that I do fiddling around on compiler explorer? e.g. I like making little snippets faster
Sorry I wasn't able to answer your question. What have I ever done to make you treat me so disrespectfully? Business must not be going well if you need to come online and grill computer hobbyists like me.
I was talking about the last paragraph, i.e. I was just pointing out that it's well trodden ground lest that OP accidentally wastes their time assuming they wouldn't be doing it for the technical challenge
I started programming at a pretty early age and I've always (probably from the first time I saw an emulator) had a goal to code an emulator myself. I start and abandon hobby projects all the time, so it took me quite a few tries to actually get some traction. But when I finally did, and I got to the point where I could see the BASIC prompt on my C64 emulator it was an amazing feeling of accomplishment. It was a great learning experience, not just making the emulator, but the whole journey to learn enough to finally make it happen. I highly recommend it if that kind of thing interests you, if not, then don't do it, do something that interests you instead.
Fun stuff. There's quite a few tutorials out there on emulating an NES too if this is your thing.
What I want to know though is are there any good tutorials on writing circuit simulators? I haven't come across any yet. Probably not as common since it requires some physics and electronics knowledge.
I have written a few 6502 and Z80 and 680000 emulators over the years of my career for different machines. And also ported MAME and a few other open source emulators to consoles. I think I am most proud of the Atari VCS emulator with the 6502 recompiler I wrote the the SONY PSX and the Gameboy Advance. Though I was also quite happy with getting my Atari VCS emulator running on the SONY PS2, emulating six separate games at once on a rotating cube. Writing an emulator teaches you quite a bit about machine architecture and optimization strategies.
Technically, yes. And technically, the Internet Archive would be committing copyright infringement by archiving this page. Is anyone actually going to get sued over this, probably no.
But, according to the laws of copyright, the context is the creator’s to share or not. And, to take down if they so please.
