(In reply to:

"Am I the only one who thinks encoding the opcode data in as few
characters as possible isn't the greatest idea? As it is now, I think
this makes for compact but rather unreadable code. Not the best idea
for maintainability. To me, clarity is more important than small size.

I'm 100% in favor of declarative programming, but I would have used
templates, or some script that generates C++ functions (e.g.: one per
opcode) from some table describing the opcodes in detail. I did something
like this for an x86 backend I implemented. It contains a JSON table that
is almost straight out of the intel manual. The table is fairly lengthy,
but adding support for more opcodes is a matter of minutes.

Anyways, maybe I'm missing the point and this guy is trying on purpose
to make his code as short as possible.")

My response:

  There are two reasons.

  The most important one is that I was making a 15 minute YouTube video.
  I had to fit my emulator creation process, from begin to end, into 15
  minutes. In order for it to be possible for people to read the text,
  it should be as short as possible (because after all, average number of
  characters per second ends up being total number of characters divided
  by video length). Now naturally I cannot fit the whole design process
  in 15 minutes; it took me several weeks after all. Instead, I took the
  source code and tried to type it in most natural and self-explanatory
  manner. (If you pay attention, you may notice that I do not immediately
  write a finished program in the video. I create it in parts, and at some
  points, I first create a simple and working implementation, which I then
  change into something more complex, adding features.)

  The second reason is that the whole opcode table is effectively machine
  code. It is not meant to be changed by a human; only observed. It was
  entirely generated by another program that I wrote in PHP. That another
  program deals with addressing modes, instruction templates, and a table
  of opcode names--addressing modes--opcode numbers. Information that you
  and I can understand. As such, the interior of the Ins() function does
  not need to be understandable; only the generator has to. But because
  I still had to enter the contents of the Ins() function within the
  video, I had to make sure it is at least fascinating to watch, which
  involved making a clear layout and inserting good and relevant comments
  for each microinstruction. Why did I not present the generator in the
  video then? Time limit. If one is truly interested, they can follow the
  links in the video description to find all the resources related to the
  creation of that emulator.

  Note that this explanation only covered the CPU emulation part, but in
  principle it applied to the whole emulator. With the PPU emulator, and
  the APU emulator, a large portion of the codegolfy style came from the
  need to fit the whole code into 15 minutes. A small part of it is due
  to the design choices (in particular, the statemachine in the PPU), and
  the rest of it is just my style. I do like concise and expressive code
  that accomplishes many things with few words.
  Linguistically, I like the Finnish language (my native language), because
  you can compress a lot of meaning into one multiply conjugated word,
  rather than using a heap of auxiliary words, such as prepositions and
  conjunctions. The desire to exercise that freedom permeates my actions
  in any artistic endeavor -- and I think fundamentally programming is
  (an) art more than it is a science.