x6502

Dev tools

cpu emulator

SHOW HN2013

88points
69comments
#271of 1,739 in 2013
Top 16%of 2013 by points

How HN took it

CuriousMostly questions and neutral comments

5 positive, 11 neutral or asking, 1 mixed, 3 critical, out of 20 comments about the project. Thread score +0.15.

Design: 3 for, 2 againstPerformance: 1 for, 0 againstDocs: 0 for, 1 againstExecution: 1 for, 0 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

  • Code is easy to read and well structured

    From 2 comments
    • 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…
      anatoly on HN
    • 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…
      jsaxton86 on HN
  • Switch-based opcode dispatch is a sensible choice

    From 2 comments
    • 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…
      userbinator on HN
    • > 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…
      pcwalton on HN

Objections

  • Large switch statements are a code smell in maintainable code

    From 2 comments
    • 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.
      Sharlin on HN
    • The README is completely broken in movie devices due to everything being inside the `code` block :(
      brianfryer on HN

Requests

  • Add a guide to reading the source order in the README

    From 1 comment
    • 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…
      anatoly on HN
  • Fix README rendering on GitHub code blocks

    From 1 comment
    • The README is completely broken in movie devices due to everything being inside the `code` block :(
      brianfryer on HN

Questions

  • How to assemble the 6502 examples on OSX

    From 1 comment
    • Recommended way to assemble the 6502 examples on OSX?
      emilyst on HN

Alternatives named

  • libz80 Z80 emulator

    From 1 comment
    • 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…
      ggambetta on HN
  • oriculator

    From 1 comment
    • 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…
      haldean on HN

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/6932711)