Show HN: I made an easy-to-understand 6502 emulator in pure C

by haldean • 13 years ago

88 69 13 years ago

jsaxton862• 13 years ago

One of the most interesting parts of this code to me was the switch statement in the main loop. Professionally, I have run into programs that have massive switch statements with hundreds of cases in them, which I've always considered a "code smell". Your approach is interesting -- breaking everything up into logical groups, putting them in separate files, then using the preprocessor to put everything back together -- that's the first time I've seen that.

I'm still not sure how I feel about it -- you could argue that you have the same problem, but now it's spread out over many files. At the same time, I can look at the loop and have a pretty good idea of what it does and I can easily find what I'm looking for. I guess without OO, there isn't a great solution to the problem, although yours is probably a slight improvement, with the added bonus of getting me to think about the preprocessor in a new way.

Good work.

alextingle• 13 years ago

Doing it once is fine. The problems start when this technique is used liberally throughout a 1,000,000 line "enterprise" application.

userbinator6• 13 years ago

IMHO there's no much simpler way to write a CPU emulator than as a huge switch inside a loop as that models quite well what a real CPU does. Anything more just obfuscates the essence of the functionality.

jimmaswell2• 13 years ago

I suppose you could create a dictionary of opcode -> function pointers. In C# that'd be like

    var ops = new Dictionary<Opcode, Action<opcodeArgs>> ()
    { 
        {0, nop },
        {1, add },
        ...
    }

or even better, maybe I'd get a list of the opcodes with their names, name all the functions after those names exactly, then use reflection to automatically create this dictionary.

Then in the main loop,

    ops[opcode].Invoke(args);

I don't know if something like that would be any use in C, though.

jsaxton862• 13 years ago

At a previous job, there was a legacy UI application that had a 10,000+ line file called "messloop.c". It consisted of a function called messloop(), which was an infinite loop with a massive switch statement inside of it. I never had to work on it, but I'm told it was a maintenance nightmare.

So when I read the author's code and saw the way he handled a similar problem, I was intrigued. If you had to deal with a massive switch statement with thousands of cases, it would probably be easier to maintain IMHO.

For a hobby project, the author's solution is 100% correct and I'm not critiquing it at all. In fact, the only reason I even commented was because I thought his solution was better than any other procedural solution I had seen before.

With that said, in an enterprise environment, where maintainability is crucial, I'd argue that a massive switch statement is probably a bad idea. Going back to messloop.c, what happens if the user tries to change a floating point value through the UI? Well, I can tell you that there is a case statement for that somewhere in messloop.c. What is that case statement called? I'm not sure, all I know is it's a #define that I'm sure made sense to the original author. It's basically a needle-in-a-haystack problem.

pcwalton• 13 years ago

Professionally, I have run into programs that have massive switch statements with hundreds of cases in them, which I've always considered a "code smell".

Most optimizing compilers will emit a jump table for a switch, which is a good way to get a reasonably high performance interpreter while keeping the code pretty clean. The performance is better than using virtual methods [1].

[1] http://www.complang.tuwien.ac.at/forth/threading/

Sharlin3• 13 years ago

It's still a code smell. It might be a justifiable code smell in some very specific circumstances where the performance actually matters, but a code smell nevertheless.

haldean14• 13 years ago

Thanks! The one downside is that the local variables that are in scope (and heavily used) in the opcode handlers are all in a different file, which is super weird, but. On the other hand, I get the performance advantage of the switch statement jump table and, like you said, it's a lot easier to find whatever I'm looking for. I think it turned out a net win.

brianfryer• 13 years ago

The README is completely broken in movie devices due to everything being inside the `code` block :(

EpicEng2• 13 years ago

Even with OO, what would you suggest? A bunch of classes, classes, inheritance, and virtual methods to replace it? Great, now my logic is spread out all over the place.

I know that there are definitely cases in which an OO approach beats a bunch of switch statements scattered throughout the code (specifically, when checking the type of the input variable), but I don't think that applies here. If I saw an interpreter written in that way I would assume it was created by someone who didn't know what they were doing.

As an aside, 1) I can't stand the term "code smell" as it tends to be used by hipsters with little to no experience building complex systems, and 2) I realize that you posted your honest thoughts and did a good job of analyzing the approach taken by the author. I'm not trying to prop up a straw man here.

bromagosa• 13 years ago

When most people hear OO they understand C++... NesTalk is a good, real OO aproach to a machine emulator:

http://smalltalkhub.com/#!/~zeroflag/NesTalk

fit2rule2• 13 years ago

I just wanted to say that 'code smell' predates hipsters as a term, yo, and a lot of very experience engineers are right when they say 'this code smells' (i.e. I am suspicious of its suitability for consumption..) In my experience the term is something I learned in the 70's from the smelly retiring hippies whose code I had to maintain for a decade or so. ;)

fit2rule2• 13 years ago

Compare your observations of this project, with what you may feel about the 6502 emulator in oriculator:

https://code.google.com/p/oriculator/source/browse/trunk/650...

Which do you find easier to read/understand/work on? In my case, I still think the #include'd switch case's to be less readable in comparison .. although it must be admitted that oriculator uses the C macro processor in its own nefarious ways .. "READ_ZIX;" indeed .. ;)

(BTW, oriculator is a very mature 6502 emulator .. and also rocks as a way to return to the glory days of the 80's machines that never got enough love: the Oric-1 and Atmos...)

haldean14• 13 years ago

oriculator is much more powerful and complex than x6502, even you ignore the non-CPU emulation bits (like video and emulated controller, which are complex and difficult). The fact that they manage to get approximately correct timing is really impressive, and involves lots more logic around opcode decoding because you need tables of how many instructions each one takes.

That said, I find it much more difficult to read. The reliance on long, complex macros means that I need to flip back and forth between the macro definitions and the opcode interpreter, and long, multi-line macros like they have give me the heebie-jeebies. I'd rather see inline functions used (like x6502 does in functions.h; the functions in functions.h serve much the same purpose as the macros in oriculator).

Not to take anything away from the project -- it's obviously an amazing software project and an incredible achievement. We just set out with different goals in mind: mine was more pedagogical, and theirs was more practical.

drblast• 13 years ago

Depending on the CPU, the compiler, and a whole host of other variables, a switch statement can be one of the better performing ways to write a virtual machine. You certainly want to avoid the overhead of many function calls.

And if you're writing a program that does one of hundreds of things based on the value of a byte, the options for really clean code are limited, and you can do a lot worse than a huge switch statement.

Here is an interesting article on the topic:

http://www.complang.tuwien.ac.at/forth/threading/

seanwoods• 13 years ago

Reminds me of "the highest level feature of C"

http://prog21.dadgum.com/166.html

"The possibilities when compiling a switch are much more varied. It can result in a trivial series of if..else statements. It can result in a binary search. Or, if the values are consecutive, a jump table. Or for a complex sequence, some combination of these techniques. If each case simply assigns a different value to the same variable, then it can be implemented as a range check and array lookup. The overall sweep of the solutions, from hundreds of sequential, mispredicted comparisons to a single memory read, is substantial."

emilyst• 13 years ago

Recommended way to assemble the 6502 examples on OSX?

voltagex_2• 13 years ago

Looking up bin/xa on Debian lead me to

    xa65 - cross-assembler and utility suite for 65xx/65816 processors

This package is available in the Mac homebrew repository, so maybe try that?

haldean14• 13 years ago

Ah yeah, sorry; xa65 is the package name on Debian as well.

Luc• 13 years ago

6502 is still currently used, by the way. The Tamagotchi games use a GeneralPlus 6502C, for example. There's a new Tamagotchi out this week that has NFC but is so much like the previous version otherwise, it's probably still using the same code:

http://natashenka.ca/tamagotchi-friends-teardown/

haldean14• 13 years ago

Talk about a blast from the past! Time to try to find a rom dump...

csmuk4• 13 years ago

The 6502 is still used widely in industrial stuff. Back in 2001 when I was still doing electrical engineering bits, as part of a project I received some brand new custom radio rig test equipment to integrate with an automated testing rig plugged into a PC running DOS (meh). We took it to bits to get access to the documented serial port header. Inside was a pristine gold turned pin socketed 6502. It was the only chip on the board that had that privilege. It was like it was being worshipped by the engineers.

We sent the test team who built it a big "you're awesome" card.

anatoly• 13 years ago

Good job! As promised, the code is easy to read. Your major choices all make sense to me:

* you went easy on #define's, they obfuscate the code when used heavily

* you have a simple switch instead of an opcode table with function pointers or something like that (may seem more fun to write, harder to read for someone inexperienced)

* light on comments, which is also excellent, the code is self-documenting almost everywhere.

* the unusual includes for opcode categories are OK. If you wanted it to be more straight-laced C, could put them in separate .c files and break the switch into many switches, one per file. It's probably better the way it is.

One thing it'd be nice to add is a short guide, right there in README, in which order to read the source (e.g. start from cpu.h/cc to understand how the state of the CPU and memory is represented, then cpu.h/cc for the main loop executed once per instruction, etc.).

haldean14• 13 years ago

Thanks so much! That's a great idea; I'll write that up.

s-macke• 13 years ago

Reminds of my little 6502 CPU project for the TI92 calculator.

http://simulationcorner.net/index.php?page=c64

Only 30KB of code and it runs a C64 on it.

ggambetta2• 13 years ago

I made something similar for the Z80: https://github.com/ggambetta/libz80

The interesting thing is that I wrote very little of the code by hand; instead I wrote a program that generates the opcode implementations from a concise specification. The end result is remarkably compact, and the whole thing was really fun to make.

csmuk4• 13 years ago

Neat solution - really like that. Great work.

userbinator6• 13 years ago

A little hint for improvement: condition() could be implemented as a switch instead of a long if-chain.

Did you use this for generating the opcodes? The Z80 ISA encoding is quite regular and octal-based: http://www.z80.info/decoding.htm

ggambetta2• 13 years ago

Thanks for the reference! This was a long time ago but I think I didn't use that decoding table. Just a couple of days ago I was reading about the x86 one, I really wasn't aware that opcodes were anything but random bytes mapped to operations.

As for the improvement, I never liked switch, for unknown reasons :) You mean an improvement in style, performance or both?

euroclydon• 13 years ago

So I'm working on an AVR emulator in pure C when I have time. 'tptacek gave me some hints on getting started: https://news.ycombinator.com/item?id=5787373

He suggested to take HEX as the input and I never looked back. I see this emulator just reads the bytes from the binary.

Does anyone know if the GCC AVR toolchain spits out a file I could do the same thing with?

haldean14• 13 years ago

Oh that's an interesting idea. I actually considered writing my own assembler to some format that I could read, but then I realized:

* It's way cooler if you can use other peoples' assemblers and still have your bytecode interpreter work

* Using other peoples' assemblers is a good way to sanity check any assumptions you made (this bit me with branches, for example; I was branching from the location of the current instruction when the spec is to branch from the location of the next instruction)

* It's easier to read binary than to read hex strings and transform them to binary.

Plus, transforming binaries to readable hex is as easy as "hexdump -c". :)

slunk• 13 years ago

"dispatching out to functions to handle each opcode carries unnecessary overhead in what should be the tightest loop in the project"

How about inline functions or macros?

mambodog• 13 years ago

If you want to try this out without building it yourself, I've put together a quick Emscripten port, including the two demos: http://jamesfriend.com.au/x6502

Show HN: I made an easy-to-understand 6502 emulator in pure C

Related Stories